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ACRONYMS a nd abbreviations 


JDRN 

Japanese Dam Reception Node 

JPL 

Jet Propulsion Laboratory 

kbps 

Kilobits Per Second 

LAN 

Local Area Network 

LOR 

Line Outage Recorder 

LZP 

Level Zero Processing 

Mbps 

Megabits Per Second 

MB 

Megabytes 

MO&DSD 

Mission Operations and Dam Systems Directorate 

MODLAN 

Mission Operations Division Local Area Network 

MODNET 

MO&DSD Operational/Developmental Network 

MTBF 

Mean Time Between Failures 

MTTR 

Mean Time to Restore 

N/A 

Not Applicable 

NASA 

National Aeronautics and Space Administration 

NASDA 

National Space Development Agency 

Nascom 

NASA Communications (Network) 

Nascom II 

Augmented Nascom (Network) 

NCC 

Network Control Center 

NCDS 

NASA Climate Dam System 

NMCC 

Network Management Control Center 

NSGW 

Nascom Service Gateway 

NSSDC 

National Space Science Dam Center 

OSI 

Open System Interconnect 

OSL 

Orbiting Solar Laboratory 

Pacor 

Packet Processor 

PMSS 

Pacor Matrix Switch Subsystem 

POCC 

Payload Operations Control Center 

PR 

Precipitation Radar 

Prod 

Production 

Q 

Quadrature 

Q/A 

Quality and Accounting 

QL 

Quick Look 

QLP 

Quick Look Processing 
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ACRONYMS AND ABBREVIATIONS 


SDAC 

SIRT 

SMEX 

SN 

socc 

SOHO 

SOW 

SSA 

SSM/I 

STDN 

STGT 




Retransmission Message 
Retransmission Requeue f 
Request for Proposal J 
Remote Interface Unjt 
Reliability, Maintainability, Availability 
Rough Order of Magnitude 
Recorder Processor Pjtckeuzer 
Reed- Solomon 
Real Time 

Real-Time Processing 

Science Data Analysis Center 
Synchronou/lntelligent Remote Terminal 
N^Small Explorers 
|pace Network 

sience/Operations and Control Center 
>o»ar and Heliospheric Observatory 
Statement of Work 
S-B-and Single Access 
SpeciaKSensor Microwave Imager 
Spaceflight Tracking and Data Network 
Second TEtRS Ground Terminal 


TBD 

TBR 

TDCF 

TDM 

TDRS 

TDRSS 

TRMM 

TSDIS 


To Be Deferifuned 
To Be Resolve 
TRMM Data Capture Facility 
Time-Division Multiplexed 
Tracking and Data Relay Satellite 
Tracking and Data Relay Satellite System 
Tropical Rainfall Measuring Mission 
TRMM Science Data anoTnformation System 


VCID 

VIS/IR 


Virtual Channel Idendfier 
Visible/Inffared 


wsc 

WSGT 


White Sands Complex 
White Sands Ground Terminal 


XTE 


X-Ray Timing Experiment 
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ACRONYMS AND ABBREVIATIONS 


Retx Msg 

Retransmission Message 

Retx Req 

Retransmission Request 

RFP 

Request for Proposal 

RIU 

Remote Interface Unit 

RMA 

Reliability, Maintainability, Availability 

ROM 

Rough Order of Magnitude 

RPP 

Recorder Processor Packetizer 

R-S 

Reed- Solomon 

RT 

Real Time 

RTP 

Real-Time Processing 

SDAC 

Science Data Analysis Center 

SIRT 

Synchronous Intelligent Remote Terminal - 

SMEX 

Small Explorers 

SN 

Space Network 

socc 

Science Operations and Control Center 

SOHO 

Solar and Heliospheric Observatory 

SOW 

Statement of Work 

SSA 

S-Band Single Access 

SSM/I 

Special Sensor Microwave Imager 

STDN 

Spaceflight Tracking and Data Network 

STGT 

Second TDRS Ground Terminal 

TBD 

To Be Determined 

TBR 

To Be Resolved 

TDCF 

TRMM Data Capture Facility 

TDM 

Time-Division Multiplexed 

TDRS 

Tracking and Data Relay Satellite 

TDRSS 

Tracking and Data Relay Satellite System 

TRMM 

Tropical Rainfall Measuring Mission 

TSDIS 

TRMM Science Data and Information System 

VCID 

Virtual Channel Identifier 

VIS/IR 

Visible/Infrared 

WSC 

White Sands Complex 

WSGT 

White Sands Ground Terminal 

XTE 

X-Ray Timing Experiment 
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1.0 INTRODUCTION 

The National Aeronautics and Space Administration (NASA) and the National Space 
Development Agency of Japan (NASDA) initiated the Tropical Rainfall Measmng Mission 
(TRMM) to obtain more accurate measurements of tropical rainfall than ever before. Tnes 
measurements will be used to improve scientific understanding andknowledgeofthe 
mechanisms effecting the intra-annual and interannual variability of the Earth s climate. 
The success of the TRMM is largely dependent upon the handling and processing of the 
measurement data by the TRMM Ground System supporting the mission. 

The TRMM Ground System is a multiple-facility system that encompasses many eating 
NASA institutional facilities. TRMM Ground System elements include Payload 
Operations Control Center (POCC) and Command Management System (CMS); the 
TRMM Data Capture Facility (TDCF); the TRMM Science Dam and Information System 
(TSDIS), which includes the Science Data An alysis Center (SDACjand the Science 
Operations and Control Center (SOCC); the Flight Dynamics Facility (FDF); the- Japanese 
data reception node (JDRN); the National Space Science Data Center (NSSDC), ground 
truth stations and other non-TRMM data sources. These facilities communicate using 
NASA institutional services such as the NASA Communications Network (Nascom), 
augmented Nascom Network (Nascom II) or, for geographicaUy-proximaw facilities, Local 
Area Networks (LANs). Space-to-ground communications between the TRMM spacecratt 
and the TDCF (return link) and the POCC (forward link) are provided by the Space 
Network (SN), with the Deep Space Network (DSN) providing backup communications in 
the event of an SN failure. 


1.1 OBJECTIVE AND SCOPE OF STUDY 

The objectives of this study are to define the data capture and processing requirements for 
the TRMM Data Capture Facility and to use those requirements to design and evaluate two 
independent TDCF implementations. The first implementation is based on the existing 
Packet Processor (Pacor) at Goddard Space Flight Center (GSFC). The second 
implementation is based on the Customer Data Operations System (CDOS). The Pacor- 
based implementation results in a local TDCF at GSFC; the CDOS-based implementation 
results in a remote TDCF at the Whitejands Complex (WSC) in Las Cruces, New 
Mexico. 


The scope of this study is limited to the functions performed by the TDCF. These 
functions include capturing the TRMM spacecraft return link data stream; processing the 
data in the real-time, quick-look, and routine production modes, as appropriate; ana 
distributing the resulting real time, quick-look, and production data products to users. 
Higher-level processing (beyond Level Zero) and analysis are handled by other TRMM 
Ground System elements and are beyond the scope of this study. 


1.2 TRMM MISSION OVERVIEW 

The principal objective of the TRMM is to obtain three years of climatological 
determinations of rainfall in the tropics, culminating in data sets of 30-day average rainfal 
over 5-degree square areas, and associated estimates of vertical distribution of latent neat 
release. The rainfall data are needed to enhance existing atmospheric general circulation 
models for both research and large-scale weather prediction. The vertical latent heat protile 
data are needed to enhance models of the 30-to-60-day tropical oscillation m rainfall and 
wind fluctuations and other models concerning the effects of tropical atmosphere on distant 
air motion. 
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dtaal rainfall cycle. The projected spacecraft operational life is ° f the 

The TRMM scientific instrument complement currently envisioned mnciete e 
instruments: a Precipitation Radar (PR)- two passive microwave „,?• consist8 four 
frequency Electronically Scanning MiCTOwav^RadK 1 ' the S , mgle ' 

meteorological missions The PR a Tanan^cA in ^ cen flown on previous space 
precipitation radar flown in space and w(u provide ^SSfme^Semeras „ f rSt qUantitativ ' 

p s ^ a "f ss 

The AVHRR measurements will he anXii heat reIease P. roflle ca " be estimated, 
microwave rainfall measurements to allow 'hener ' ^ n ^ tIon Wlt .^ die an d passive 
measurements from past and fut^C^rationd'sateUites. lnter P retatIon of other VIS/IR 

^^m^TDRS^onC^perCrbit* to Tracking and Data Relay Satellite 

(WSGT) or Second TDRS Ground Terminal rCTrrw ^.irce. 3 - -- Ground Terminal 

Will transmit the data* to die TDCF forCrocessin Jin^? reaftl WSC - V? Y SGT OT STGT 
mode. The appropriate resultine dara nSS,/,! Cfi ,n ^-“TK-PUKk-loolt. or production 
the TRMM Ground Sys?em ? d ‘T bu " d to other elements of 
States, the PDF, and the TTJDIS at gIfc n^TSDIS SOr?!"™ roas h of United 

planning and instrument monitoring and coordLtiom toTSDTC %nFZ " S2b e for S ence 
higher-level processing of DroducHnn data SDAC is responsible for 

from supporting field experiments reauired far Hat tS Anci ? lar y ground truth data and data 
at the TSD1S. Lra pX“S^?TsK *. 

via electronic or non-electronic mncnrfrt mB ni,n • m ^ availa ble to TRMM scientists 

Science Team, data products will be released roTheNSSDCa" GS P FCfar by C' TRMb ! 
distribution to general users. ' at ObFC for archiving and 

1.3 TRMM END-TO-END SYSTEM DESCRIPTION 

arrows appe^ng^^ system is illustrated in Figure 1-1. The 

interfacessuch as post-evm rmmlti Conve / pnmary datafl °ws only; control 
products are not shown. The broad striDed^nrn ^f^ 0511 ? 158100 of data or data 
supported by Nascom Nascom II or an alfArrtnf indicate interfaces that will be 

TDCF implemenrati^ considered m \£Z Lf i TZ mC ^!? nS link - i e P endi "S <» the 

rs b a ^ M 5 

baselined but that may evennraUy be implemented subj^TmSngo^g^oS, " 0W 
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Figure 1-1. TRMM End-to-End System Concept 














NSSDC, was presented in Section 1.2. Subsections 1.3.1, 1.3.2, and 1.3.3 address the 
elements comprising the spacecraft data system, the SN, and the TRMM Ground System, 
respectively, in terms of their functions in the end-to-end system concept. A more detailed 
concept of mission operations from data generation on-board the spacecraft through the 
distribution of Level Zero products by the TDCF is presented in Section 2 and will not be 
discussed here. 

1.3.1 Spacecraft Data System 

Instrument and spacecraft data are input to the on-board Communications and Data 
Handling (C&DH) subsystem to be formatted and transmitted to the TRMM Ground 
System via the TDRSS and other elements of the SN. The C&DH subsystem is composed 
of four primary components: the Synchronous Intelligent Remote Terminal (SIRT), the 
RIU-to-1773 Adapter, the Recorder Processor Packetizer (RPP), and the Command 
Telemetry Terminal (CTT). These components communicate using a MIL-STD 1773 fiber 
optic data bus. With the exception of the SIRT, these C&DH components are adaptations 
of the C&DH components being developed for the Small Explorers (SMEX). The SIRT 
will be a new component developed specifically for the TRMM C&DH. The RIU-to-1773 
Adapter maps a standard RIU interface to the 1773 data bus and is used primarily for the 
spacecraft power subsystem interface. The RIU-to-1773 adapter is not applicable to the 
remainder of this discussion and will not be addressed further. An overview of the 
applicable TRMM C&DH components and the TRMM instrument complement is illustrated 
in Figure 1-2. 

The SIRT is a 8086 processor-based terminal that provides the instrument interface to the 
1773 bus. The SIRT serves as the C&DH gateway to each instrument for the receipt of 
instrument science and engineering data and the transmission of commands back to the 
instrument. The SIRT performs the necessary packetization functions for instrument 
science and engineering data transport on-board the spacecraft and over the space-ground 
link. It also performs any required depacketization functions for command and ancillary 
data transfer to the instruments. A design option currently under consideration may 
transfer some of the packetization functions to the RPP for the data to be stored on the solid 
state recorder for playback to the return link. Under this option, the SIRT will continue to 
provide the instrument interface to the bus. 

The RPP is based on the 80386 32-bit microprocessor and contains a number of 
communications interfaces, including the MIL-STD 1773 data bus, a RS-449-like serial 
twisted wire channel, and a differential RS-232 interface for asynchronous 
communications. The RPP also contains an 82380 Direct Memory Access (DMA) 
controller for data transfers, such as dumps to memory, that do not require processor 
intervention. Two RPPs are among the C&DH components. Each RPP provides an 
interface to 2 (TBR) gigabits (Gb) of solid state memory which will permit the storage of 
nearly two orbits of data. The RPP is the primary C&DH computer that performs on-board 
processing and command and telemetry packetization as required. The RPP sequentially 
identifies the return link data packets with an application process identifier (APID), 
generates the real time and playback virtual channels, and generates the fill virtual channel 
as necessary to meet the return link transmission rate of 2 Mbps. 

The CTT provides the prime interface from the C&DH subsystem to the TDRS transponder 
and performs low-rate I/O and time-distribution functions. The CTT is 8086 processor- 
based and provides a backup capability for command and control of the data system. It 
also provides the hardware for encoding telemetry to, and decoding commands from, the 
transponder. Encoding and decoding functions include cyclic redundancy code (CRC) 
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Figure 1-2. C&DH Component Overview 


checks and convolutional encoding. Hooks for the addition of Reed-Solomon ( - ) 
encoding are present. Commands are received from the transponder and forwarded via t e 
1773 link to the bus controller. Telemetry is transferred using either the 1773 bus (low 
rate) or a dedicated serial channel from the RPP (high rate). 


1.3.2 Space Network 

The SN relays return link and forward link data between the TRMM spacecraft and the 
TRMM Ground System. The elements of the SN include the TDRSS, WSGT, STGT and 
Network Control Center (NCC). As illustrated in Figure 1-1, the TDRSS relays the data 
between the TRMM spacecraft and the WSGT or STGT under control of the NCC, the 
WSGT or STGT relays the data between the TDCF (return link) or POCC (forward link) 

and the TDRS. 


1.3.3 TRMM Ground System 

The TRMM Ground System contains many diverse supporting elements. These include the 
POCC CMS TDCF, FDF, TSDIS, JDRN, ground truth stations, other non-TRMM data 
sources, and the NSSDC. TRMM Ground System elements communicate using Nascom 
Nascom II, or LANs. Nascom resources are coordinated with the NCC; Nascom u 
resources are coordinated with the Network Management Control Center (NMCC). 
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The POCC is the operations and control center for the TRMM spacecraft. The POCC is 
responsible for monitoring and maintaining the health and safety of the TRMM spacecraft 
and its instrument complement. It manages and controls the core systems, including data 
management, power, thermal, and control systems, and monitors the payload usage of 
spacecraft resources. The POCC analyzes spacecraft and instrument telemetry data 
received from the WSGT or STGT and generates instrument and spacecraft commands 
necessary to ensure mission health and safety. These commands, along with instrument 
commands generated by the TSDIS, are uplinked to the spacecraft via the POCC interface 
with the SN WSGT and STGT. Additional details regarding the forward link operations 
concept are presented in Section 2.4. 

The CMS checks instrument commands and software updates generated by the TSDIS 
SOCC to ensure that the commands and updates are valid and that existing instrument 
resource allocations are not exceeded. Ancillary data generated by the FDF are also verified 
and validated. Valid data, software updates, and commands are transmitted to the POCC 
for subsequent uplink to the spacecraft. 

The 1 DCF receives return link data from the WSGT or STGT, performs error checking 
and correction, provides data quality and accounting information at the frame and packet 
APID level, and separates packets by APID. The TDCF provides real-time, quick-look, 
&nd production processing, m&intsins 3. short-tenn d&tE store, and formsts data products for 
distribution to the TRMM data users by electronic or physical media. Section 2 3 provides 
a detailed operations concept for the TDCF. 

The FDF provides orbit, attitude, and navigation computational services in support of flight 
projects and science customers. Prelaunch services include mission design analysis, 
trajectory analysis, sensor analysis, and operations planning. Operational support services 
include orbit and attitude determination, anomaly resolution, maneuver planning and 
support, sensor calibration, post-delta velocity analysis, and generation of planning and 
scheduling data products. TRMM orbit and attitude parameters are verified and if 
necessary, repaired by the FDF using engineering data from the spacecraft. The repaired 
orbit and attitude results are transmitted to the TSDIS for use in instrument operations and 
^ ata processing (Levels 1 through 4), and to the CMS for eventual uplink to the 
TRMM spacecraft. The FDF also plans and schedules TRMM orbital maneuvers in 
coordination with the TSDIS, and provides orbital maneuver parameters to the POCC via 


The TSDIS is responsible for science planning and instrument monitoring and 
as higher-level processing of Level Zero data products provided 
by the TDCF. Since instrument control options are limited, the POCC will perform 
instrument commanding using the CMS, based upon TSDIS SOCC-provided science 
plans. Instrument failures will be addressed by the SOCC providing functional command 
requirements to the POCC for execution using predefined command sequences Software 
repair will be done off-line and transmitted to the CMS for validation and verification and 
subsequent uplink to the spacecraft via the POCC. Level 1 through 4 data products are 
scientists and, after release approval by the TRMM Science Team, to 
the NSSDC for archiving and subsequent distribution to general users. 

T!?® TrFcf^if ^ ata rece P^ on n °de is the location within the continental United States 
(CONUS) where Japanese users may pick up their production data products. 

The ground truth stations provide remote and in situ measurements from the Earth's surface 
supplemented by special experiments with instrumented aircraft. These data are used to 


1-6 


validate TRMM measurements, aid mission sampling analysis studies, and develop key 
regional climatologies. Data are currently being gathered both on-shore and off-shore near 
Cape Canaveral, Florida, at a monsoon site near Darwin, Australia, and at an ocean site in 
Kawajalein Atoll, Marshall Islands. 

Other non-TRMM data sources include, among others, meteorological satellites such as the 
Geostationary Operational Environmental Satellite (GOES) and Geostationary Meteorology 
Satellite (GMS). The imagery data from these satellites will be received electronically a 
compared to the TRMM radar imagery. 

The NSSDC is the permanent archive and distribution center for all TRMM data 

are transferred to the NSSDC on durable media after certification by the TRMM Science 
Team at the TSDIS. In addition to direct distribution, a number of services i will be 
available to participating science users through the NASA Climate Data System 
The NCDS functions as an interactive scientific information management system that 
provides an integrated set of tools for locating, manipulating, and displaying climate 
research data. TRMM products will be included in the NCDS as rapidly as the data 
products are approved for release by the TRMM Science Team. 
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Operations Concept and Data Systems Requirements", June 1988. 

"Packet Telemetry", Recommendation CCSDS 102.0-B-2, Blue Book Issue 2 
Consultative Committee for Space Data Systems, January 1987 or later issue. 

"Telemetry Channel Coding", Recommendation CCSDS 101.0-B-2, Blue Book Issue 2 
Consultative Committee for Space Data Systems, January 1987 or later issue. 

OctobTr^^S? 6006 Steering GrOUp for a Tr °P ical Rainfall Measuring Mission", Draft, 

Report" J jSfy li 27 ti< I 98 |^ eSearC h ’ ' ,TRMM Science Data Processing System Phase A Study 

*2fE» R 0ani Jf’ al \’ "A Proposed Tropical Rainfall Measuring Mission (TRMM) 
Satellite , Bulletin American Meteorological Society, Vol. 69, No. 3, March 1989. 

r^sn?^i a n d R P i ai l} : “ Serv , ic ^ Architectural Specification", Recommendation 
1987 ofl at« iaue ’ ' Consul,auve for S P^ Data Systems, 

"Telecommand, Part 2: Data Routing Service, Architectural Specification" 

wS?? 11 CCSDS 202.0-B-l, Blue Book, Issue 1, Consultative Committee for 
Space Data Systems, January 1987 or later issue. 

Telecommand, Part 3: Data Management Service, Architectural Definition " 

CC ,SDS 203 O-B-l, Blue Book, Issue 1, Consultative Committee for 
Space Data Systems, January 1987 or later issue. 


1.5 REPORT ORGANIZATION 

Section 2 describes the TRMM operations concepts for instrument operations, spacecraft 
operations, return link data processing and forward link data handling. The return link data 
processing concept addresses real time telemetry, quick-look and production processing 
Concepts subsequent to Level Zero processing and distribution by the TDCF are beyond 
the scope of this document and are not discussed y 
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Section 3 defines the baseline requirements that must be satisfied by the selected TDCF 
implementation, including system capabilities, communications and data standards, external 
interfaces, and system functional, performance, and operations requirements. 

Section 4 identifies the mission assumptions and issues that may impact the TDCF 
implementation. These assumptions and issues should be validated prior to the final 
selection of the TDCF implementation. 

Section 5 defines the logical and physical interfaces between the TDCF and external entities 
and communication networks. 

Section 6 presents the two TDCF architecture and design options that are the primary focus 
of this study. The two options are described in terms of the system configuration, 
operations concepts, development and operating costs, and advantages and disadvantages. 

Section 7 provides an analysis of the critical issues and trade-offs resulting from the 
architecture and design options presented in Section 6. 

Section 8 provides recommendations for the final TDCF implementation selection process. 

Appendix A provides a Glossary of Terms that defines the terminology used in the context 
of this study. 
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2.0 TRMM MISSION OPERATIONS CONCEPT 


This section presents the general operations concept envisioned for the Tropical Rainfall 
Measuring Mission. In order to understand the overall TRMM operations concept, it is 
necessary to have a broad understanding of the operations occurring on-board the 
spacecraft, such as data formatting and transmission to ground facilities, as well as the 
operations occurring on the ground. Instrument and spacecraft operations concepts are 
assumed to remain constant for all TRMM ground data handling scenarios. Return link 
processing and forward link handling are specific to each TDCF implementation scenario. 
Instrument operations, spacecraft operations, return link processing, and forward link 
handling are addressed in the subsections th a t follow. 


2.1 INSTRUMENT OPERATIONS 

There are four instruments comprising the TRMM complement: the Advanced Very High 
Resolution Radiometer (AVHRR), the Electronically Scanning Microwave Radiometer 
(ESMR), the Special Sensor Microwave Imager (SSM/I), and the Precipitation Radar (PR). 
These instruments operate continuously, 24 hours a day, 7 days a week. Functional 
descriptions of each of these instruments were presented in Section 1.3.1. 

The AVHRR generates data at an average rate of 50 kilobits per second (kbps), including 
housekeeping data. The data are transmitted as a bit stream to a SIRT component of the 
TRMM platform C&DH subsystem. In the initial design configuration, the SIRT provides 
the packetization necessary for further data transport within the C&DH (1773 data bus) and 
to the ground (Consultative Committee for Space Data Systems (CCSDS) Packet Telemetry 
Recommendation, January 1987). 

The ESMR generates data at a rate of 1 kbps. Housekeeping data are also generated at a 
very low rate. Science and housekeeping data are transmitted as a bit stream to a C&DH 
SIRT for packetization and data transport. 

The SSM/I generates data at an average rate of approximately 4.3 kbps, including 
housekeeping data. The data are transmitted as a bit stream to a C&DH SIRT for 
packetization and data transport. 

The PR generates data at a continuous rate of 85 kbps, including housekeeping data. The 
PR will utilize a NASA provided SIRT to perform the necessary CCSDS and 1773 bus 
packetization. 

Each instrument receives commands, ancillary data, and software updates via the C&DH 
subsystem and the instrument's associated SIRT. Commands may be forward-linked in 
real time from the ground during a TDRS contact or retrieved from on-board storage. 
Commands forward-linked in real time from the ground may result from the presence of 
new targets of opportunity, the need for instrument recalibration or realignment as 
evidenced by scientific interpretation of the instrument science data, or the need for 
instrument safing to protect the health and safety of the instrument, the spacecraft, or both. 
Commands stored on-board the spacecraft are limited to commands that can be readily and 
accurately predetermined and defined, such as safing sequences or periodic orbit and 
attitude adjustments. 
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2.2 SPACECRAFT OPERATIONS 


The TRMM spacecraft generates housekeeping data specific to the spacecraft (as opposed 
to the instruments) at a rate of 1-2 kbps. These data are used by the POCC to monitor the 
health and safety of the TRMM spacecraft and its instrument complement. 

Instrument and spacecraft return link data are input to the on-board C&DH subsystem and 
formatted into source packets in accordance with the CCSDS Packet Telemetry (Version 1) 
Recommendation (CCSDS 102.0-B-2, January 1987). Each packet is assigned an APID 
which identifies the packet's ground processing and routing requirements. As a minimum, 
each instrument's packets are assigned an APID unique to the instrument; other APIDs are 
assigned as necessary (e.g., ancillary data). The resulting CCSDS packets are recorded on 
the primary solid state recorder on-board the spacecraft for playback during scheduled 
TDRS contacts. The baseline spacecraft configuration utilizes an interface that will make 
the recorder look like a large circular buffer. After recording data from the first orbit it will 
continue to record the next orbit subject to the constraint that an orbit pass buffer may not 
be overwritten until a ground command is sent to release that buffer. The second solid state 
recorder acts as a flight spare and is activated upon failure of the primary recorder or upon 
receipt of an activation request from the POCC. Both recorders are capable of 
simultaneously recording and replaying data. The data are replayed over a maximum of 
eight virtual channels. It is assumed that one virtual channel identifier (VCID) will be 
assigned to the real-time data transmitted to the ground, one VCID will be assigned to fill 
frames, and up to six VCIDs will be assigned to playback data. These assignments have 
not been finalized. 

During TDRS contacts, the recorded packets are played back in forward order (the order in 
which they were recorded), multiplexed and placed into the data field of the CCSDS 
Version 1 Transfer Frame, which is the data structure within the packet telemetry system 
that transports CCSDS packets across the space-to-ground link in a standardized manner. 
Version 2 packet telemetry segmentation, as defined in the CCSDS Packet Telemetry 
Recommendation (CCSDS 102.0-B-2, January 1987), is not supported, nor is any use of 
segmentation flags in Version 1 source packets. Transfer Frames are then assigned, by 
means of a VCID, to any one of up to six virtual channels available for the transmission of 
playback data over the physical channel. 

Real-time data, i.e., instrument and spacecraft data generated during the TDRS contact, are 
packetized and multiplexed into Transfer Frames by the C&DH in the manner described for 
the recorded data. These Transfer Frames are assigned to a single virtual channel which 
has been reserved exclusively for real-time data transfer. Real-time packets are also 
recorded on one of the spacecraft recorders in order to ensure against the loss of any data 
generated during the TDRS contact. 

Transfer Frames are encoded by the C&DH to provide error protection and a means of 
assessing data quality on the ground. The R-S encoding scheme specified in CCSDS 
102.0-B-2 (Packet Telemetry, January 1987) is currently baselined to be implemented on- 
board the TRMM spacecraft 

The return link rate is assumed to be a constant 2 Megabits per second (Mbps). The 
C&DH generates fill Transfer Frames as necessary to maintain the 2 Mbps rate; these 
Transfer Frames are assigned to a single virtual channel reserved for that purpose. The 
real-time and fill virtual channels are then interleaved with the playback virtual channel(s) to 
produce a single physical channel. 
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2.3 RETURN LINK PROCESSING 

A general overview of the return link processing operations concept is presented in this 
subsection. This scenario differs slightly for each of the TDCF implementations 
considered. The return link processing operations concepts specific to each TDCF 
implementation are presented in Section 6. 

Return link of the physical channel is accomplished using the SN. The TDCF receives the 
TDRS acquisition session schedule from th e NCC. In accordance with the established 
schedule, the TDRS relays the data to the WSGT or the STGT located at the WSC in New 
Mexico. The WSC then forwards the d a ta to the TDCF using the Nascom II* Network, 
which consists of a number of gateways connected by long-distance communications links. 
The data are transferred to the Nascom II Network at the return link rate of 2 Mbps. 

Return link data are processed as real-time telemetry, quick-look data, or routine production 
data. The type(s) of processing to be performed are initially determined on the basis of 
virtual channel assignment. Real-time data may be processed in real-time and production 
modes; playback data may be processed in quick-look and production modes. The Nascom 
II Network does not have the capability to separate the virtual channels comprising the 
physical channel, and so routes the entire physical data stream to both the POCC and the 
TDCF. The POCC performs the necessary error checking and correction functions and 
then separates the data stream into its component virtual channels to identify the real-time 
telemetry data; the playback and fill virtual channels are discarded. The TDCF also 
performs error checking and correction functions, separates the data stream into its 
component virtual channels, captures the real-time and playback virtual channels on a 
nonvolatile physical medium, and, depending on the TDCF implementation, either stores or 
discards the fill virtual channel. Real-time and playback virtual channels are stored by the 
TDCF for a period of 2 years. In addition, quality and accounting information are 
generated by the TDCF for each real-time and playback virtual channel. Real-time, quick- 
look, and production processing are then performed by the TDCF on the basis of the APID 
and user requirements. 

2.3.1 Real-Time Processing 

As noted in the previous paragraph, the return link data stream is routed to the POCC for 
use in monitoring spacecraft and instrument health and safety. The data are transmitted at a 
rate of 2 Mbps, the rate at which they are received by Nascom n, in order to minimize the 
delay incurred in delivering and analyzing the data. Under this concept, the POCC is 
required to perform the virtual channel separation and any packet processing necessary to 
support health and safety monitoring. 

Real-time telemetry processing performed by the TDCF is limited to packet demultiplexing 
and, on the basis of APID, data quality and accounting. Each real-time packet is 
transmitted to the TSDIS SOCC for use in science planning and instrument monitoring and 
coordination upon completion of the demultiplexing and quality and accounting procedures; 
summary session-level quality and accounting information is transmitted following the last 
packet comprising the real-time primary data set. Real-time primary data sets are bounded 
by a single APID and a single TDRS contact. The real-time data transmission rate from the 
TDCF to the TSDIS is assumed to be 200 kbps or less. 


*It is assumed throughout this document that Nascom II has the capability to interface 
directly to the WSGT or STGT at the WSC. If this assumption is incorrect, existing 
Nascom facilities will be used to transfer the data from the WSC to the TDCF. 
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2.3.2 Quick-Look Processing 

Data requiring quick-look processing represent a small fraction of the data return-linked by 
the TRMM spacecraft. In TRMM's case no more than 3 TDRS contacts per day will be 
provided quick-look processing. Data are identified as requiring quick-look processing on 
the basis of the VCID, the APID, and the TDRS acquisition session previously specified by 
the user. 

Quick-look processing reconstructs data sets to approximate the form of data generated by 
the TRMM instruments or by the TRMM spacecraft Only playback data are used in quick- 
look processing; no merging of real-time data with playback data or redundant data deletion 
is performed. Quick-look processing demultiplexes the source packets from the designated 
playback virtual channel(s), sorts the packets by APID, time-orders (sequences) the packets 
in accordance with the packet sequence control fields in the packet primary header and 
annotates the data with indicators describing data quality. The source pa cket time code in 
the packet secondary header may be used to resolve any ambiguities in the packet sequence 
control field. The primary data set and quality indicators are then formatted as a quick-look 
data product for distribution to users. Quick-look primary data sets are bounded by a 
single VCID, single APID, and a single TDRS contact. 

Quick- look data products containing science, engineering, and ancillary data are distributed 
to the TSDIS SDAC for science coordination. Quick-look data products containing 
ancillary data are distributed upon request to the FDF for refinement or repair of the orbit 
and attitude data or calibration of the attitude sensors. Distribution occurs within 2 hours of 
receipt of the last bit of data comprising the quick-look data set by the TDCF. The data 
transmission rate from the TDCF to the TSDIS is assumed to be 1 Mbps, although a higher 
rate is being discussed. The transmission rate from the TDCF to the FDF is TBD. 

2.3.3 Production Processing 

All real-time and playback data, including the playback data designated to receive quick- 
look processing, are processed to Level Zero by the TDCF. The production primary data 
set comprises all packets with the same APID whose time codes lie between the defined 
start and stop time for the data set. 

In routine production processing, packets are first demultiplexed from the virtual channels. 
On the basis of the APID, the TDCF reconstructs data sets to exactly match the form of the 
data generated by the TRMM instruments and the TRMM spacecraft. Reconstruction of 
these data sets requires time-ordering the data, including merging real-time and playback 
data as necessary, removing redundant packets resulting from the merging process, and 
identifying gaps (missing packets) in the data in addition to the functions of data quality 
annotation and data set formatting described for quick-look processing in Section 2.3.2. 

Production primary data sets are bound in 24-hour periods and must be delivered to the 
user within 24 hours after the receipt of the last bit of data defining the primary data set. 
The oldest data in the production data product is never more than 48 hours old. Production 
data products containing science, engineering and ancillary data are distributed to the 
TSDIS SDAC for higher-level processing (Levels 1 through 4) and to the JDRN via 
Nascom II facilities. Production data products containing ancillary data are distributed to 
the FDF for refinement and calibration, and to calculate definitive orbit and altitude. The 
data transmission rate from the TDCF to the TSDIS and to the JDRN is assumed to be 1 
Mbps; the transmission rate from the TDCF to the FDF is TBD. 
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2.3.4 Return Link Data Recovery and Retransmission 

The TDCF performs quality and accounting checks on the incoming return link data strearm 
If the quality of the data falls below specified perfonnance criteria and is deemed 
unacceptable (too many uncorrectablc errors, too many mtssmg^sferFram^.crc^ the 
TDCF alerts the POCC. The current data are processed by the TDCF as if the data were or 
acceptable quality The POCC examines the quality of its received data and, if appropriate, 
reauests reSmission from the NCC. If the NCC is unable to effect the retransmission, 
the POCC may request retransmission of the data from the TRMM spacecraft. The capacity 
of cachof the dual on-board recorders provides the capability to recover data for a penodo 
up to 2 orbits, or approximately 3 hours, after the initial dump. The reo^smission reque 
must be sent to the spacecraft within 1.5 hours of the initial dump to effect activauo 
snare recorder and prevent loss of new data or overwnung of the requested data on the 
primary recorder. The data are retransmitted to the ground via the SN and are reprocessed 
E i acwrdance with the real-time processing, quick-look processing, and production 
processing scenarios described in Sections 2.3.1, 2.3.2, and 2.3.3, respective y. 

If Nascom II experiences a line outage or the TDCF experiences a catastrophic failure that 
otherwise impacts the TDCFs capability to receive the return link data stream, the data may 
be retransmitted from the WSGT or STGT line outage recorder (LOR). Data recovery from 
the LOR is permitted only in the event of a line outage or a catastrophic fac ih ty failure. TL 
LOR data recovery period is limited to 5 hours after acquisition of the data by the WbO 1 or 

STGT. 

On occasion, it may be necessary for a TDCF user to request retransmission of raw 
(captured) data or processed (production) data sets. Raw data may be recovered at anytime 
within the 2-year storage period from the TDCF long-term data store and reoransmitted 
S by line y replay, if In llectronic interface between the user and the TDCF ex, SB, or by 
magnetic tape if no electronic interface exists. The user must specify thedate :anc timrfs of 
the desired TDRS acquisition session(s), as well as the appropriate VCID(s) and APID(s). 
Routine production data products are stored for 72 hours. Within this designated st ° ra §^ 
period, production data products may be retransmitted by line replay over the electronic 
interface to the user. Subsequent to the designated storage penod, routine production data 
products must be recovered from the Level 1A data stored by the TSDIS. 


2.4 FORWARD LINK HANDLING 

Several types of data are forward linked to the TRMM spacecraft by TRMM ground 
facilities. These data types include commands to both the instruments and the TRMM 
spacecraft, ancillary data such as orbit and attitude parameters, and software updates. 

Instrument commands are generated by TRMM instrument scientists in response to the 
results of analyses performed on their instrument data, targets of opportunity identified in 
the observation area, or instrument health and safety issues. These commands are 
forwarded from the TSDIS SOCC to the CMS for validation and verification and then to 
the POCC for uplink to the spacecraft via the SN. 

Spacecraft commands are generated by the POCC in response to spacecraft health and 
safety issues, required orbit and attitude adjustments, or other necessary calibrations. The 
POCC may also issue instrument or spacecraft safing commands if required to ensure 
spacecraft health and safety. These commands are uplinked to the spacecraft by the POCC 

via the SN. 
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Ancillary data are generated by the FDF or the TSDIS SOCC and uplinked to the spacecraft 
and individual instruments via the CMS, the POCC, and the SN. These data include 
parameters related to spacecraft orbit and attitude, among others, and are necessary for the 
proper interpretation and analysis of the data generated on-board the spacecraft. The 
ancillary data are assigned an APID unique to ancillary data on-board the spacecraft and 
retransmitted to the ground with the science and engineering data for analysis via the SN. 

Updates to on-board software may be generated by either the TRMM instrument scientists 
or the POCC. Software updates may be necessary to correct a previously- undetected error 
in the instrument software or to enhance instrument or spacecraft operations. Updates 
generated by TRMM scientists are validated and verified by the CMS; all updates are 
uplinked to the spacecraft via the POCC and the SN. 

The POCC uplinks all forward link data generated by TRMM ground facilities to the 
TRMM spacecraft. The forward link data are assumed to be formatted in accordance with 
the Command Operation Procedure 1 (COP-1) specified in the CCSDS Telecommand 
Recommendation, Part 2, Data Routing Service (CCSDS 202.0-B-l, January 1987). 
COP-1 is a closed-loop telecommanding protocol that utilizes ("go-back-n") retransmission 
techniques to correct telecommand frames which were rejected by the spacecraft because of 
error. The uplink is accomplished by means of a secure data link from the POCC to the SN 
WSGT/STGT. The data are transmitted to the TDRS spacecraft and relayed to the TRMM 
spacecraft. 
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3.0 BASELINE REQUIREMENTS 


The requirements contained in this section reflect an analysis of the needs of the TRMM 
Mission for Level Zero processing as viewed in the context of the current mission 
implementation concepts. Although the various documents cited in Section 1 were used as 
a starting point for this analysis, it was found that so much had changed since the Phase A 
studies that they did not serve as reliable references for the derivation of the requirements 
presented here. For that reason, specific documents are not cited for each requirement. It 
is expected that as the mission moves ahead and mission-level requirements are updated 
and accepted it will be necessary to provide the appropriate review and traceability for these 
and other element-level requirements. 

Within the context of the requirements stated in this section, "and" means that all of the 
options listed in the requirement must be implemented; "or" means that at least one of the 
options listed in the requirement must be implemented. 


3.1 SCOPE OF LEVEL ZERO FUNCTION WITHIN THE END-TO-END 
DATA SYSTEM 

The TRMM Data Capture Facility will have the primary responsibility for performing all of 
the initial processing required for the TRMM return link data received from the SN or 
equivalent backup system. This initial processing encompasses the functions required to 
receive and capture raw data through the functions required to distribute real-time, quick- 
look, and production data products to user s . 


3.2 FUNCTIONAL REQUIREMENTS 

3.2.1 System Capabilities 

3.2. 1.1 The TRMM Data Capture Facility (TDCF) shall provide the basic 
operational capabilities for reception, capture, real-time, quick-look and production 
processing, and distribution of TRMM return link digital data transmitted via the SN or 
other compatible communications networks and Nascom/Nascom II. 


3 . 2 . 1 . 2 The TDCF shall provide the basic operational capabilities for handling and 
storage of all raw return link spacecraft science, engineering, and ancillary data. 

3.2. 1.3 The TDCF shall provide the capability to perform data quality and 
accounting functions for all return link data. 

3 . 2 . 1 . 4 The TDCF shall provide the capabilities for real-time processing of the real- 
time virtual channel. 

3.2. 1.5 The TDCF shall provide the capabilities for quick-look processing of 
designated packet APID(s) received during a designated TDRS acquisition session. 

3.2. 1.6 The TDCF shall provide the capabilities for production processing of all 
TRMM CCSDS-packetized return link data. 
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3 . 2 . 1 . 7 The TDCF shall provide the timely distribution of real-time, quick-look and 
routine production data products. 

3 . 2 . 1 . 8 The TDCF shall provide the capability to prevent the loss or interruption of 
services due to abnormal or unexpected data passing through or processed by the system. 

3.2.2 Standards 

3.2.2. 1 Communications 

3 . 2 . 2 . 1 . 1 The TDCF shall provide the capability to support communications standards 
that are compliant with CCSDS recommendations, as specified in "Packet Telemetry", 
CCSDS 102.0-B-2, Blue Book, dated January 1987, for the space-ground link. 

3 . 2 . 2 . 1 . 2 The TDCF shall provide the capability to specifically support the subset of 
the communications standards identified in 3. 2. 2. 1.1 that adhere to the GSFC Aerospace 
Data Systems Telemetry Standards, Version 3.3, for the space-ground link. 

3 . 2 . 2 . 1 . 3 The TDCF shall support standard telecommunications protocols for ground- 
to-ground transport as defined by either NASA or International Standards Organization 
(ISO) accepted standards which, at the appropriate Open System Interconnect (OSI) layer, 
will permit the transparent transport of the specified CCSDS Transfer Frames and source 
packets along with other associated elements of information (e.g., space-to ground or 
ground-to-ground quality information) provided with the data. 

3. 2. 2. 1.4 The TDCF should use standard telecommunications interfaces using 
accepted protocols, as specified in 3.2. 2.1. 3, that can be supported with commercial-off- 
the-shelf equipment through the first three layers of the OSI Model to allow the exchange of 
data as required with other elements of the TRMM Ground System. 

3 . 2 . 2 . 1 . 5 The TDCF shall negotiate and execute Interface Control Documents (ICDs) 
with each interfacing TRMM Ground System element to specifically define each supported 
interface. 


3. 2. 2. 1.6 The TDCF shall adopt standards, wherever practical, that are consistent 
with the Government Open System Interconnect Profile (GOSIP). 

3. 2. 2. 2 Data Standards 

3 . 2 . 2 . 2 . 1 The TDCF shall adopt standards for data formats and data units consistent 
with those CCSDS-compatible conventions adopted by the TRMM Project. 

3.2.3 External Interfaces 

3.2.3. 1 Space Network 

3.2.3. 1.1 The TDCF shall interface with the Space Network (SN) White Sands 
Ground Terminal (WSGT) and the Second TDRSS Ground Terminal (STGT) located at the 
White Sands Complex (WSC), either directly or via Nascom/Nascom II, for the receipt of 
return link data. 
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3 . 2 . 3 . 1 . 2 The TDCF shall interface with the SN Network Control Center (NCC) for 
the receipt of TDRS schedules. 

3. 2. 3. 2 Nascom . 

3 . 2 . 3 . 2 . 1 The TDCF shall be capable of interfacing with the NASA Communications 
(Nascom) Network or the augmented Nascom (Nascom II) Network for the receipt of 
return link data. 

3 . 2 . 3 . 2 . 2 The TDCF shall be capable of interfacing with Nascom or Nascom II for the 
transmission of production data products to the designated Japanese data reception node. 

3 . 2 . 3 . 2 . 3 The TDCF shall interface with the Network Management Control Center 
(NMCC) as required to coordinate use of Nas com II facilities and resources. 

3. 2. 3. 3 Payload Operations Control Center 

3. 2. 3. 3.1 The TDCF shall interface w ith the Payload Operations Control Center 
(POCC) located at GSFC for the transmission of selected portions of the recorded 
unprocessed return link data, selected quick-look data products, and selected production 
data products, as required, and to request retransmission of return link data when 
necessary. 

3 . 2 . 3 . 3 . 2 The TDCF shall deliver selected portions of the recorded unprocessed data 
to the POCC as required. 

3 . 2 . 3 . 3 . 3 The TDCF shall transmit selected quick-look data products to the POCC as 
required for emergency situations. 

3 . 2 . 3 . 3 . 4 The TDCF shall transmit selected production data products to the POCC 
for system analysis as required. 

3. 2. 3. 4 TRMM Science Data and Information System 

3. 2. 3. 4. 1 The TDCF shall interface with the TRMM Science Data and Information 
System (TSDIS) at GSFC for the transmission of real-time, quick-look, and production 
data products. 

3 . 2 . 3 . 4 . 2 The TDCF shall provide the capability to deliver real-time data products to 
the TSDIS through a primary electronic interface. 

3 . 2 . 3 . 4 . 3 The TDCF shall provide the capability to deliver quick- look and production 
data products to the TSDIS through both a normal electronic interface and an appropriate 
electronic or non-electronic backup interface, 

3 . 2 . 3 . 4 . 4 The TDCF shall deliver real-time, quick-look and production data products 
to the TSDIS in the form of CCSDS source packets comprising primary data sets and 
associated quality and accounting information. 
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3. 2. 3. 4. 5 Science Data Analysis Center 

3. 2. 3. 4. 5.1 The TDCF shall interface with the TSDIS Science Data Analysis Center 
(SDAC) for the transmission of production data products and selected quick-look data sets. 

3. 2. 3. 4. 5. 2 The TDCF shall transmit selected quick-look data products to the TSDIS 
SDAC as required. 

3 . 2 . 3 . 4 . 5 . 3 The TDCF shall transmit production data products to the TSDIS SDAC. 

3. 2. 3. 4. 6 Science Operations Control Center 

3. 2. 3. 4. 6.1 The TDCF shall interface with the TSDIS Science Operations Control 
Center (SOCC) for the transmission of real-time data products. 

3 . 2 . 3 . 4 . 6 . 2 The TDCF shall transmit real-time data products to the SOCC as required. 

3. 2. 3. 5 Flight Dynamics Facility 

3 . 2 . 3 . 5 . 1 The TDCF shall interface with the Flight Dynamics Facility (FDF) for the 
transmission of spacecraft ancillary data products containing such information as attitude 
sensor data and any appropriate orbit/position data developed through on-board processing. 

3 . 2 . 3 . 5 . 2 The TDCF shall transmit ancillary data products to the FDF in the form of 
CCSDS source packets comprising primary data sets and associated data quality and 
accounting information. 

3 . 2 . 3 . 5 . 3 The TDCF shall transmit ancillary data products to the FDF as required. 

3. 2. 3. 6 Japanese Data Reception Node 

3. 2. 3. 6. 1 The TDCF shall int erf ace with a designated Japanese data reception node 
(JDRN) for the transmission of production data products. 

3 . 2 . 3 . 6 . 2 The TDCF shall provide the capability to transmit production data products 
to the designated JDRN via Nascom, Nascom II, or other appropriate electronic or non- 
electronic secondary interfaces. 

3 . 2 . 3 . 6 . 3 The TDCF shall transmit production data products to the JDRN in the form 
of CCSDS source packets comprising primary data sets and associated quality and 
accounting information: 

3. 2. 3. 6. 4 The TDCF shall transmit production data sets to the designated JDRN using 
a protocol that supports the transparent delivery of the data products. 

3. 2. 3. 7 Deep Space Network 

3 . 2 . 3 . 7 . 1 The TDCF shall interface with the Deep Space Network (DSN) via Nascom 

or Nascom II for the receipt of return link data in the event of a catastrophic failure of the 
SN. 
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3.2.4 Data Handling and Data Processing 

3.2.4. 1 Reception and Capture 

3 . 2 . 4 . 1 . 1 The TDCF shall provide the capability to receive and capture all TRMM 
return link data (except fill data, which may be excluded from capture at the option of the 
TDCF) transmitted through the SN either directly or via Nascom or Nascom EL 

3 . 2 . 4 . 1 . 2 The TDCF shall provide the capability to receive and capture all TRMM 
return link data (except fill data, which may be excluded from capture at the option of the 
TDCF) transmitted via the Deep Space Network and Nascom or Nascom II. 

3.2.4. 1.3 The TDCF shall provide data capture and storage for all return link raw 
data. 

3 . 2 . 4 . 1 . 4 The TDCF shall provide the capability to synchronize on CCSDS Transfer 
Frames. 

3.2.4. 1.5 The TDCF shall provide the capability to perform Reed-Solomon (R-S) 
error decoding and correction. 

3 . 2 . 4 . 1 . 6 The TDCF shall provide the capability to separate the return link physical 

channel into virtual channels. 

3.2.4. 1.7 The TDCF shall provide the capability to interpret the Transfer Frame 
header information in a manner consistent with CCSDS standards. 

3 . 2 . 4 . 1 . 8 The TDCF shall provide the capability to discard fill Transfer Frames from 
return link data. 

3 . 2 . 4 . 1 . 9 The TDCF shall provide the capability to demultiplex CCSDS packets from 
Transfer Frames. 

3.2.4.1.10 The TDCF shall provide the capability to aggregate non-identifiable data 
(e.g., packets having unreadable headers) into a separate permanent data set. 

3.2.4.1.11 The TDCF shall provide the capability to monitor, store, and report the 
quality of return link virtual channels. Characteristics monitored and stored shall include, 
but may not be limited to: total number of Transfer Frames received, number of Transfer 
Frames with errors, number of detected R-S errors, number of detected R-S errors 
corrected, number of missing Transfer Frames, and number of times Transfer Frame sync 
was lost. 

3.2.4.1.12 The TDCF shall provide the capability to initiate appropriate and timely 
retransmission or data recovery procedures in the event that the data quality fails to meet 
predefined criteria. 

3. 2. 4. 2 Production Processing 

3 . 2 . 4 . 2 . 1 The TDCF shall provide the capability to routinely process all TRMM data 

packets including instrument science, spacecraft and instrument engineering and health and 
safety data, and ancillary data. 
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3 . 2 . 4 . 2 . 2 The TDCF shall provide the capability to construct primary data sets, each 
of which contains packets identified by a single Application Process Identifier (APID) and a 
source time code between a predefined start and stop time. 

3 . 2 . 4 . 2 . 3 The TDCF shall provide the capability to merge real-time data with playback 
data having the same APID in the processing of production data sets. 

3 . 2 . 4 . 2 . 4 The TDCF shall provide the capability to order data packets received during 
a single TDRS acquisition session using the source packet sequence count contained in the 
primary packet header. 

3 . 2 . 4 . 2 . 5 The TDCF shall provide the capability to use the source packet time code 
contained in the secondary packet header to resolve any ambiguities in the source packet 
sequence count 

3 . 2 . 4 . 2 . 6 The TDCF shall provide the capability to delete redundant data packets as 
necessary. 

3. 2. 4. 2. 7 The TDCF shall calculate the Cyclic Redundancy Code (CRC) for each 
packet and shall compare the calculated value to the return-linked CRC remainder when 
provided with the packet. 

3. 2. 4. 2. 8 The TDCF shall provide the capability to identify and flag, according to 
specified formats and reports, missing data within each primary data set, or between 
successive ordered data sets, using information from the packet headers. 

3 . 2 . 4 . 2 . 9 The TDCF shall provide the capability to construct predefined data products 
reflecting mission needs from data contained in one or more specified APIDs by grouping 
the specified processed primary data sets into a single data file. 

3.2.4.2.10 The TDCF shall provide the capability to generate and include data quality 
and accounting information with the production data sets forwarded to users. 

3.2.4.2.11 The TDCF shall provide the capability to collect identifiable "orphan" 
packets which have become separated from and were not included in a previously-delivered 
data product, and combine them into complete blocks of data for transmission to the 
recipients of the original data product upon request. 

3.2.4.2.12 The TDCF shall provide the capability to temporarily store all production 
data products for a designated period to permit a limited retransmission capability for all 
scheduled transmissions to users. 

3.2.4.2.13 The TDCF shall production process Precipitation Radar data, along with 
other instrument, engineering and ancillary data packets as required, for delivery to the 
designated JDRN. 

3. 2. 4. 3 Real-Time Processing 

3 . 2 . 4 . 3 . 1 The TDCF shall provide the capability to identify data requiring real-time 
processing on the basis of the virtual channel identifier (VCID) and APID. 
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3 . 2 . 4 . 3 . 2 The TDCF shall provide the capability to perform real-time processing and 
distribution of real-time data for up to 16 TDRS acquisition sessions per day on an 
exceptional or emergency basis. Regularly scheduled real-time processing shall be limited 
to a maximum number of TDRS acquisition sessions per day. 

3.2. 4. 4 Quick-Look Processing 

3 . 2 . 4 . 4 . 1 The TDCF shall provide the capability to identify data requiring quick-look 
processing on the basis of the VCID and APID. 

3 . 2 . 4 . 4 . 2 The TDCF shall provide the capability to perform quick-look processing 
and produce primary data sets using appropriately identified playback data. Quick-look 
processing of playback data shall be available for a limited number of TDRS acquisition 
sessions per day on either a routine scheduled basis or on an emergency quick-response 
basis. 

3. 2. 4. 5 Data Distribution 

3 . 2 . 4 . 5 . 1 The TDCF shall provide the capability to transmit TRMM data products to 
their designated destination(s) without alteration of the data contents. 

3 . 2 . 4 . 5 . 2 The TDCF shall provide the capability to group primary data sets and their 
associated quality and accounting information into predefined data products using 
prescribed header information and to transmit those data products to designated users. 

3 . 2 . 4 . 5 . 3 The TDCF shall provide the capability to distribute real-time data packets to 
users immediately upon completion of real-time processing using primary or backup 
electronic distribution methods. 


3. 2. 4. 5. 4 The TDCF shall provide the capability to transmit quick-look and 
production data products containing quality and accounting information on a data set basis. 

3. 2. 4. 5. 5 The TDCF shall provide the capability to electronically distribute in an 
expedited mode quick-look data products obtained from processing selected playback data. 

3. 2. 4. 5. 6 The TDCF shall provide the capability to utilize a backup distribution 
channel for quick-look data products. 

3 . 2 . 4 . 5 . 7 The TDCF shall provide the capability to distribute production data products 
by primary electronic or non-electronic methods as required for timely utilization by each 
user. 

3 . 2 . 4 . 5 . 8 The TDCF shall provide an appropriately commensurate backup mode for 
each of the primary electronic or non-electronic distribution methods. 

3 . 2 . 4 . 5 . 9 The TDCF shall provide the capability to support the concurrent distribution 
of data products to the TSDIS SDAC and the JDRN. 

3.2.4.5.10 The TDCF shall support the electronic distribution of appropriate production 
data products including, but not limited to, Precipitation Radar and associated engineering 
and ancillary data to the JDRN. 
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3.2.4.5.11 The TDCF shall provide the capability to retransmit production data 
products upon user request in the event that initial transmissions to a user are unsuccessful 
and the retransmission requests are made within a designated period after the initial 
transmission attempt. 


3.3 SYSTEM PERFORMANCE REQUIREMENTS 

3.3.1 Throughput 

3 . 3 . 1 . 1 The TDCF shall provide the capability to receive return link data at a peak 
aggregate rate of up to 2.4 Megabits per second (Mbps). 

3 . 3 . 1 . 2 The TDCF shall provide the capability to receive up to 8 concurrent return 
link virtual channels. 

3 . 3 . 1 . 3 The TDCF shall provide the capability to receive any single return link 
virtual channel having a maximum rate of up to 2 Mbps. 

3 . 3 . 1 . 4 The TDCF shall provide the capability to throughput data at an average rate 
of 200 kilobits per second (kbps) (TBR). 

3.3. 1.5 The TDCF shall provide sufficient capacity to process an average 
throughput rate of 240 kbps (TBR), which includes a 20% contingency, for periods of up 
to 24 hours. 

3.3. 1.6 The TDCF shall provide the capability to transmit quick-look and 
production data products to the POCC at a minimum aggregate rate of 1 Mbps (TBR). 

3.3. 1.7 The TDCF shall provide the capability to transmit quick-look and 
production data products to the TSDIS SDAC at a minimum aggregate rate of 1 Mbps 
(TBR). (Note: A rate of 5 Mbps is being requested and will be reviewed for this 
interface.) 


3 . 3 . 1 . 8 The TDCF shall provide the capability to transmit real-time data products to 
the TSDIS SOCC at a minimum aggregate rate of 177 kbps (TBR). 

3.3. 1.9 The TDCF shall provide the capability to transmit quick-look and 
production spacecraft ancillary data products to the FDF at a minimum aggregate rate of 


3.3.1.10 The TDCF shall provide the capability to transmit production data products 
to the designated JDRN at a minimum aggregate rate of 1 Mbps (TOR). 

3.3.1.11 The TDCF shall provide the capability to concurrendy capture all return link 
data and process real-time data for up to 16 acquisition sessions per day. 
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3.3.2 Real-Time, Quick-Look, and Production Processing 

3.3 . 2 . 1 The TDCF shall provide the capability to perform real-time processing, 
including transmission to a user’s comm u nication link, of received and reassembled 
packets for a designated APID within 1 (TBR) second of receipt of the data. The TDCF 
shall generate and report summary quality information for the entire TDRS acquisition 
session. 

3 . 3 . 2 . 2 The TDCF shall provide the capability to perform real-time processing for 
up to 16 TDRS acquisition sessions per day as required for a maximum period of 3 days. 
Regularly-scheduled real-time processing shall be limited to a maximum of 3 TDRS 
acquisition sessions per day. 

3 . 3 . 2 . 3 The TDCF shall provide the capability to process and electronically deliver 
quick-look data products to users within 2 hours (TBR) of reception of the last bit of data 
included in the defined quick-look primary data set 

3 . 3 . 2 . 4 The TDCF shall provide the capacity to perform quick- look processing for 
up to 3 TDRS acquisition sessions per day. 

3 . 3 . 2 . 5 The TDCF shall provide the capability to process and electronically deliver 
routine production data products to users within 24 hours of reception of the last bit of data 
comprising the defined primary data set 

3. 3. 2. 6 The TDCF shall provide the capability to process and deliver routine 
production data products via non-electronic media within 36 hours of reception of the last 
bit of data comprising the defined primary data set. 

3.3.3 Storage Capacity 

3 . 3 . 3 . 1 The TDCF shall provide the capability to capture and store a daily volume of 
raw return link data of at least 2.2 Gigabytes (TBR). 

3 . 3 . 3 . 2 The TDCF shall provide data storage for unprocessed return link data for 2 
years. 

3 . 3 . 3 . 3 The TDCF shall provide the capability to transmit raw (unprocessed) data 
upon request via electronic or non-electronic methods as expeditiously as the production 
schedule permits. 

3 . 3 . 3 . 4 The TDCF shall provide the capability to retain production data products for 
a maximum of 72 hours (TBR) in order to confirm delivery of die data to users. 

3. 3. 3. 5 The TDCF shall provide the capability to retransmit production data 
products via electronic distribution methods within 1 hour of receipt of a retransmission 
request received within the 72-hour storage period. 
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3.4 OPERATIONAL REQUIREMENTS 

3.4.1 Reliability 

3 . 4 . 1 . 1 The TDCF shall provide a Mean Time Between Failures (MTBF) in excess 
of 1000 (TBR) hours. 

3.4.2 Maintainability 

3 . 4 . 2 . 1 The TDCF shall meet a Mean Time To Restore (MTTR) of not greater than 
1 (TBR) hour. 

3. 4. 2. 2 The TDCF shall have the capability to transfer from the primary to a 
secondary mode of data distribution for transmitting routine production data products to the 
TSDIS and the designated JDRN within 24 hours of a primary distribution system failure. 

3. 4. 2. 3 The TDCF shall have the capability to transfer from a primary to a 
secondary mode of data distribution for transmitting real-time and quick-look data products 
to the TSDIS and the POCC within 1 hour of a primary distribution system failure. 

3.4.3 Availability 

3 . 4 . 3 . 1 The TDCF shall provide the capability to support operations 24 hours a day, 
7 days a week on a continuous basis. 

3 . 4 . 3 . 2 The TDCF shall provide an availability in excess of 0.9990 (TBR). 
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4.0 ASSUMPTIONS 


This section highlights the assumptions that have been made with regard to the mission 
requirements and/or currently planned mission implementation that will have some impact 
UDon the TDCF. Since the Project is still in a formative stage and the final needs of the 
Project have not been completely codified, this section reflects our best understanding o 
the current mission requirements as of September 1990. These assumptions generally 
serve as the bases for the Level Zero processing requirements identified in Section 3. it 
future needs of the Project evolve in such a way as to make these assumptions 
inappropriate it will be necessary to review the related requirements and update them 
accordingly. It is also quite possible that implementation characteristics and resulting 
design conclusions will be affected by any changes in these assumptions. 


The assumptions presented in this sec tion were developed to facilitate the design of the 
TDCF architectures and the definition of appropriate operations scenarios. These 
assumptions are not intended to impose requirements on the TRMM spacecraft or 
supporting systems such as the SN, Nascom, Pacor or CDpS. If the assumptions made 
are determined to be inappropriate to the mission or supporting systems, the related 1DC 
requirements, architectures and operations scenarios should be updated to reflect any 
necessary changes to the assumptions. 


4.1 SCHEDULE 

4 . 1.1 The TRMM spacecraft will be launched in August 1997. It should be noted that an 
earlier date is being reserved by the Japanese launch facilities. If this earlier date is 
accepted it will significantly affect the recommendations of this study. 

4.1.2 The first month after launch will be util ized for system checkout. 

4.1.3 The operational life shall be 3 years. 

4.1.4 System- level testing of the entire TRMM Ground System will begin no later than 
June 1996. 

4.1.5 TRMM Ground System elements, including the TDCF, will be functional and will 
have completed essential element testing by June 1996 in order to support system-level 
testing. 


4.2 DATA RATES 

The following is a summary of the baseline data rates expected to be generated on-board the 
spacecraft and included in the return link as well as the expected forward link data rates to 
the spacecraft. 

4.2.1 Science Instruments 


AVHRR 

50 

kbps 

SSM/I 

4.3 

kbps 

ESMR 

1 

kbps 

Precipitation Radar 

85 

kbps 

Total Science Rate 

140.3 

kbps 

Maximum Science Rate 

169.3 

kbps 


4-1 


It should be noted that over the past several months the instrument data rate for the A VHRR 
has been reduced by about 30 kbps to its current value of 50 kbps. There is also some 
discussion regarding the best estimate of the average rate for the Precipitation Radar. In 
addition, discussions and studies are underway that may result in the change-out of several 
of the instruments, replacing them with a single instrument and resulting in a net increase in 
the current estimate of the data rate by about 20 kbps. To handle this uncertainty in the 
estimate of the data rate, the TRMM Project is assuming a cumulative instrument data rate 
of 169.3 kbps in its initial design studies. This number is being considered as a not-to- 
exceed value for spacecraft design and presumably will continue to -serve that purpose until 
all instrument selections are finalized and revised best estimates are accepted by the Project 
Scientist and the Project. For purposes of this study we will use the same approach. Since 
the currently estimated data rates appear to be smaller than the baseline, however, it is 
assumed that the overhead associated with all packet level artifacts (primary and secondary 
headers and any error control trailers) is a conservative 3.3% of the total input science 
stream. With these assumptions the following values are used in this study: 


4.2.2 

Maximum Allowable Science Data Rate 
(assumed to include all packet-level artifacts) 

175 

kbps 

4.2.2. 1 

Present Science Data Rate Estimate 
(assumed to include all packet-level artifacts) 

145 

kbps 

4.2.3 

Spacecraft/Instrument Engineering/ 
Health and Safety 

2 

kbps 

4.2.4 

Total Packet-Level Data Rate 
(generated on the spacecraft ) 

177 

kbps 

4.2.5 

Maximum Frame-Level Overhead 

23 

kbps 

4.2.6 

Maximum On-Board 
Data Generation 

200 

kbps 

4.2.7 

Nominal Return Link 

2 

Mbps 

4.2.8 

Emergency Return Link 

2 

kbps 

4.2.9 

Nominal Forward Link 

1 

kbps 

4.2.10 

Maximum Forward Link 

2 

kbps 


4.3 SPACECRAFT DATA FORMAT 

4.3.1 The TRMM spacecraft will utilize packet telemetry communications standards that 
are compliant with CCSDS recommendations, as specified in "Packet Telemetry", CCSDS 
102.0-B-2, Blue Book, dated January 1987, for the space-ground link. 

4.3.2 Reed-Solomon error decoding and correction will be supported for the return link 
data. 

4.3.3 No Version 2 packet telemetry segmentation or use of segmentation flags, as 
defined in CCSDS 102.0-B-2, will be supported. 
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4.3.4 A small number of APIDs (of the order of 10 or less) will be used to identify return 
link packets. 

4 3 5 The spacecraft will require only 3 virtual channels to support the transport of real- 
time, playback, and fill data. A maximum of 8 virtual channels will be permitted (1 real- 
time! 1 fill, and up to 6 playback (TBR)). 

4.4 ANCILLARY DATA HANDLING 

4.4.1 The orbital positions propagated on-board the spacecraft and ^smitted down with 
the instrument data will be of sufficient accu racy to be used directly by the TSDIS without 
correction by FDF. 

4.4.2 Any attitude sensor data that requires additional processing for use in science data 
processing and analysis will be formatted into separate packets and assigned appropriate an 
APID to permit routing to the FDF or the TSDIS as appropriate. 

4.4.3 Spacecraft engineering data required for science data processing and analysis will 
be formatted into CCSDS source packets. 

4.4.4 Instrument engineering data required for science data processing and analysis will 
be combined with the instrument science data and formatted into packets having an APID 
unique to the instrument that generated the data. 

4.4.5 All spacecraft and/or instrument data generated during a TDRS contact that are 
required for operational control will be formatted into packets and assigned to the real-time 
virtual channel which the POCC will be capable of processing independently. 


4.5 ON-BOARD DATA RECORDING 

4.5.1 The spacecraft will utilize two solid state recorders, each capable of storing more 
than one orbit's data. 

4.5.2 All data, including any data broadcast as real-time data, will be stored on the flight 
recorders and broadcast as playback data. 


4.6 RETURN LINK STRATEGY 

4.6.1 The SN (TDRSS and WSC) will provide the space-to-ground link to support the 
transmission of all return link data from the TRMM spacecraft to the ground. 

4.6.2 Spacecraft contacts will occur 16 times per day for a maximum of 10 minutes each 
contact. 

4.6.3 All return link data (real-time and playback) will be transmitted on a single physical 
channel, specifically the TDRS S-band Single Access (SSA) Quadrature (Q) channel. 

4.6.4 Nominally, all return link data will be transmitted to the TDRS using a directional 
dish on the TRMM spacecraft. 
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4.6.5 In the event of an emergency, instrument and spacecraft engineering and health and 
safety data will be transmitted to the TDRS using the omni-directional antenna on the 
TRMM spacecraft. 

4.6.6 In the event of a failure in the SN, instrument and spacecraft engineering and health 
and safety data will be transmitted to the DSN using the omni-directional antenna on the 
TRMM spacecraft 

4.6.7 Real-Time data will be assigned a unique VCID and will be interleaved with 
playback data during TDRS contacts. 

4.6.8 Playback data will be assigned one or more unique VCIDs. 

4.6.9 Playback data will be transmitted on the return link in forward time order, i.e., the 
order in which the data were recorded on-board the spacecraft. There is no requirement to 
reverse the order of playback data on the ground. 

4.6.10 There will be a unique virtual channel designation for fill data required to maintain 
the 2 Mbps return link rate. 

4.7 REAL-TIME PROCESSING 

4.7.1 Real-Time processing will be limited to no more than 3 scheduled acquisition 
sessions per day to support science instrument testing, calibration, and field experiments 
through the TSDIS. 

4.7.2 There is no requirement to deliver any real-time data to the Japanese users or to any 
users other than the TSDIS as noted in 4.7.1. 


4.8 JAPANESE USERS 

4.8.1 Japanese users will be provided with production data products on a standard 
delivery schedule with electronic delivery to a JDRN on the west coast of the United States. 

4.8.2 Nascom II will provide an interface between the TDCF and the JDRN to support 
the required delivery of production data products. 

4.9 TDRSS BACKUP APPROACH 

4.9.1 In the 1997+ time frame, there will be sufficient internal backup within SN such 
that additional backup will be a low priority. 

4.9.2 If required, the DSN will provide the necessary backup to the SN. The TRMM 
Ground System will be capable of interfacing with the DSN. 


4.10 DATA STORAGE 

4.10.1 The mission processing requirement that imposes a 2-year storage period 
for maintaining a backup copy of all raw data is considered valid. This requirement is 
under review in light of current policy directions. 
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4.10.2 There is no requirement on the TDCF to archive or maintain any long-term 
storage of production products. The TSDIS will archive Level 1A products, from which 
Level Zero products can be recovered. 


4.11 DATA DISTRIBUTION 

4.11.1 The Nascom II Network will provide all electronic communications links 
required to transport unprocessed data and real-time, quick-look, and production data 
products to their destinations. 

4.11.2 The Nascom II Network will adopt a protocol identical to the 4800-bit 
Nascom block to allow the continued support of missions and facilities currently using the 
existing Nascom network. 

4.11.3 The Nascom II Network will have the capability to interface directly to the 
WSGT and STGT at the WSC to support data transport to the TDCF. If this assumption is 
incorrect, existing Nascom facilities will be used. 


4.12 TDCF WORK LOAD ESTIMATES 


4.12.1 Ingest Rate: Peak 2.0 Mbps (16 contacts/day, 10 minutes/contact) 

Average 196.7 kbps (Packet level, Playback+Real-Time) 

222.2 kbps (Frame level, Playback+Real-Time) 


4.12.2 Processing: Production 

1,912 

- r ' ' 

MB per day (All 16 contacts per day, 

Playback data - additional Real-Time 
data if necessary) 


177 

kbps daily average throughput rate 

Quick-Look 

359 

MB per day (3 of 16 contacts/day, 

Playback data, 120 MB/contact) 


33.2 

kbps daily average throughput rate 

Real-Time 

213 

MB per day (16 contacts/day, 

Real-Time data, 13.3 MB/contact) 


19.7 

kbps daily average throughput rate 

4.12.3 Distribution: Production 

3.8 

GB per day (1.9 GB to GSFC(local), 
1.9 GB to JDRN) 

Quick-Look 

359 

MB per day (120 MB to GSFC - 3 times/day) 
(Small amounts to other users occasionally.) 

Real-Time 

213. 

MB per day (13.3 MB to GSFC 
- 16 times/day) 

Tapes/Disks 


It is assumed that no regularly scheduled data 
will be sent by tape or disk. Only 
unscheduled occasional event data will be 
sent using this mode. 


A graphic summary of the work load estimate is presented in Figure 4- 1 . 
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4.13 CDOS 


4 13 1 All functions related to data handling, from data receipt and capture through 
the processing and distribution of real-time, quick-look, and production data products, will 
be performed by the CDOS Data Interface Facility (DIF) located at the White Sands 

Complex (WSC). 


4.13.2 The CDOS data archive will have sufficient capacity to satisfy the TRMM 
requirement to store raw data for a period of 2 years. 

4.13.3 The CDOS data archive will accommodate the short-term storage of 
production data products necessary to permit limited retransmission to users. 


4.14 PACOR 

4.14.1 The Pacor will be an available support option for TRMM in the 1996-2000 
time frame. 

4.14.2 Current institutional planning calls for the Pacor to be upgraded to meet the 
requirements of TRMM. 

4.14.3 The basic fault-tolerant design of the Pacor, with redundant processors each 
having 0.98 availability and the concurrent 0.9999 availability of the GBRS, will permit the 
Pacor implementation to meet the RMA requirements of TRMM with no additional changes 
beyond those required to meet the performance requirements. 


4.15 FORWARD LINK DATA 

4.15.1 Forward link data will be formatted in accordance with the CCSDS COP- 1 
protocol specified in "Telecommand, Part 2: Data Routing Service, Architectural 
Specification", Recommendation CCSDS 202.0-B-l, Blue Book, January 1987 or later 
issue. 
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5.0 EXTERNAL INTERFACES 

This section provides a discussion of the interfaces between the TDCF and external 
facilities and communication networks. T he in terfaces and interface descriptions presented 
are based on the generic TRMM end-to-end data system concept illustrated in Figure 1-1. 
Both data and control interfaces are ad dresse d in this section. Any differences in the 
physical interfaces or in the data types, formats, or data rates flowing across these generic 
interfaces that are specific to the Pacor and CD OS TDCF implementations are discussed in 
the appropriate system configuration description for each implementation in Section 6. 

Figure 5-1 is a modified N-squared diagram that illustrates the interfaces between the 
TDCF and external facilities and communi ca tion networks. Interfaces among the external 
facilities and networks are beyond the scope of this document and are not shown. Tables 
5-1 A and 5- IB summarize, to the extent they are known, the characteristics of the data 
flowing across each interface shown in Figure 5-1. Table 5-1A summarizes the 
characteristics of the data flows from the TDCF to the other elements; Table 5- IB 
summarizes the characteristics of the data flows from the other elements to the TDCF. 
These characteristics include data type, format, rate, and frequency of transmission. 

The TDCF will support interfaces with SN, Nascom, POCC, TSDIS, FDF, JDRN, and 
DSN. These interfaces are discussed in the subsections that follow. 


5.1 SPACE NETWORK INTERFACES 

The SN interfaces with the TDCF are provided by the WSGT, STGT, and the NCC. The 
WSGT or STGT receives the TRMM return link data stream from the TDRS and transmits 
the data to the TDCF either directly or via the Nascom Service Gateway (NSGW) located at 
the WSC. The return link data stream is comprised of CCSDS Version 1 Transfer Frames, 
and is transmitted at a rate of 2 Mbps once per TDRS contact (once per orbit). 

The NCC performs network managementfunctions for the SN, including planning and 
scheduling and data recovery and retransmission. Coordination of the TDRS acquisition 
sessions to support the TRMM is accomplished by the POCC and the NCC. The NCC 
transmits the active schedule to the TDCF on a daily basis, 16 hours prior to the first event 
on the schedule, to facilitate any reconfigurations necessary to receive and process the 
TRMM return link data stream. Any changes to the schedule subsequent to delivery of the 
active schedule to the TDCF are delivered as required. Scheduling messages are 
transmitted over a GSFC LAN using a TBD protocol. The data unit formats are defined in 
STDN No. 101.2, Revision 6, NCC Schedule Messages 94 or 99. The assumed data rate 
is TBD; schedules are updated daily or as required. 

Data recovery and retransmission functions are coordinated by the NCC as requested by the 
POCC (assuming a GSFC TDCF location). The TDCF performs quality and accounting 
checks of the return link data stream rec ei ved over the Nascom II Network. If these 
metrics do not meet predefined criteria, the TDCF sends an alert to the POCC for the data in 
question. If appropriate, the POCC sends a retransmission request to the NCC. The NCC 
initiates the requested retransmission from the appropriate source or notifies the POCC that 
the requested retransmission is not possible. The POCC then has the option of requesting 
retransmission of the data from the spacecraft. The retransmission message formats are 
TBD. The frequency of the retransmission message is as required. 
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Figure 5-1. TDCF External Interfaces 











Table 5- 1 A. Characteristics of Dataf lows from the TDCF to Other Elements 


From 

To 

Data 

Type 

Format 

Data 

Rate 

Frequency 

TDCF 

NCC 

Post-Event Rpts 
LOR Retx Req* 

TBD 

TBD* 

TBD 

TBD* 

Per Orbit 
As 

Required* 

TDCF 

NSGW 

Production 

RT* 

QL* 

Files of 
CCSDS 
Packets 

1.0 Mbps 
200 kbps* 
1.0 Mbps* 

Daily 

Schedule* 

Schedule* 

TDCF 

NMCC 

Resource Msgs 

TBD 

TBD 

As Required 

TDCF 

POCC 

Q/A Alerts 
Raw Data** 
QL** 

Production** 

TBD 

Com Blocks 
Files of 
CCSDS 
Packets 

TBD 

Mag Tape** 
1.0 Mbps** 
1.0 Mbps** 

As Required 
Request** 
Schedule** 
Daily** 

TDCF 

SOCC 

(TSDIS) 

RT 

Files of 
CCSDS 
Packets 

200 kbps 

Per Orbit 

TDCF 

SDAC 

(TSDIS) 

QL 

Production 

CCSDS 

Packets 

1.0 Mbps 
1.0 Mbps 

Schedule 

Daily 

i 

TDCF 

FDF 

QL** 

Production 

(Ancillary) 

Files of 
CCSDS 
Packets 

TBD 

Schedule** 

Daily 

TDCF 

JDRN 

Production 

Files of 
CCSDS 
Packets 

1.0 Mbps 

Daily 


implementation dependent. 
**If requested by destination. 
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Table 5- IB. Characteristics of Data Flows from Other Elements to the TDCF 


From 

To 

Data 

Format 

Data 

Frequency 


Type 


Rate 


DSN 

TDCF 

Return Link 

CCSDS 

2.0 Mbps 

Per Orbit 


Data (via 

Transfer 





Nascom II) 

Frames 



JDRN 

TDCF 

Retx Req (Prod) 

TBD 

TBD 

As Required 

FDF 

TDCF 

Retx Req 
(QL**, Prod) 

TBD 

TBD 

As Required 

SDAC 

TDCF 

Retx Req 

TBD 

TBD 

As Required 

(TSDIS) 


(QL, Prod) 




socc 

TDCF 

Retx Req 

TBD 

TBD 

As Required 

(TSDIS) 


(RT) 




POCC 

TDCF 

Tx Req 

(Raw**, QL**, 
Prod**) 

TBD 

TBD 

As Required 
As Required 



Retx Req 

TBD 

TBD 

NMCC 

TDCF 

Resource Msgs 

TBD 

TBD 

TBD 

NSGW 

TDCF 

Return Link 

CCSDS 

2 Mbps 

Per Orbit or 


Data* 

Transfer 


Retx Req 



(from SN or 
iaw Retx Req) 

Frames 



NCC 

TDCF 

TDRS Schedule 

NCC Schedule 

TBD 

Daily or As 



Msg 94 or 99 


Required 

WSGT/ 

TDCF 

Return Link 

CCSDS 

2 Mbps 

Per Orbit 

STGT 


Data 

Transfer 

Frames 




^Implementation dependent. 
**If requested by destination. 
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The TDCF sends post-event reports to the NCC following each TDRS acquisition session 
to Drovide data reception confirmation andto summarize the data transmission quality. In 
the event of a line outage or catastrophic TDCF failure, the TT>CF may request 
retransmission of any data lost during the outage or failure from the WSGT or b I U l luk. 
LOR retransmission requests are coordinated with the NCC. 


5.2 NASCOM INTERFACES 

The Nascom interfaces with the TDCF are provided by the appropriate NSGWs and the 
NMCC at GSFC. The NSGWs and NMCC are elements of the Nascom II Network.* 

If the TDCF is located at WSC, the return link data stream of CCSDS Version 1 Transfer 
Frames is transmitted directly from the WSGT or STGT to the TDCF at a rate of 2 Mbps. 
The return link data are transmitted once eveiy 90 minutes (once per TDRS acquisition 
session/TRMM orbit). Subsequent to completion of appropriate processing by the TDCF, 
real-time, quick-look, and production data products are distributed to users via the WSC 
NSGW. The data products are formatted as files of CCSDS packets. Real-time packets 
and associated summary quality and accounting information are transmitted at a rate of 200 
kbps; quick-look and production data products are transmitted at a rate of 1 Mbps. 

If the TDCF is located at GSFC, the return link data stream is transmitted to the TDCF at a 
rate of 2 Mbps via the WSC NSGW using a TBD network protocol. The GSFC NSGW 
receives the return link data and removes t he network protocol artifacts to yield a stre am of 
CCSDS Version 1 Transfer Frames. Th is d ata stream is then transferred to the TDCF in 
the Version 1 Transfer Frame format at the 2 Mbps rate. Return link data are transmitted 
once every 90 minutes (once per TDRS contact/TRMM orbit). Subsequent to completion 
of appropriate processing, the TDCF transmits production data products to the GSFC 
NSGW for transmission to the JDRN on the west coast of the United States. The 
production data products are formatted as files of CCSDS packets and are transmitted at a 
rate of 1 Mbps once per day. 

The NMCC performs the network management functions for the Nascom II Network, 
including coordinating resources for data transmission. The data transmission function is 
accomplished by the WSC and GSFC NSGWs as described in the preceding paragraphs. 
Coordination of Nascom II resources is accomplished by the TDCF and the NMCC. 


5.3 POCC INTERFACE 

The POCC interface with the TDCF is accomplished via Nascom II and a GSFC LAN if 
the TDCF is located at WSC, or via a GSFC LAN if the TDCF is located at GSFC. The 
POCC contains the Flight Operations Team (FOT) that is responsible for maintaining the 
health and safety of the TRMM spacecraft and instruments, for spacecraft operations, and 
for performing trend analyses. 

The POCC receives data quality and accounting alerts from the TDCF if the quality of the 
data received by the TDCF falls below specified criteria. The POCC evaluates the qua lty 
of the return link data stream received at the POCC and determines if data retransmission 
from the NCC or from the spacecraft is required. The format of the data quality and 
accounting alert is TBD, and may take the form of a voice communication. 


*Reference Section 4. 1 1. 
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The POCC also receives, upon request, raw (unprocessed) data and quick-look and 
pfo^jycfion data products. The raw data are used to analyze discrepancies or trends in 
successive real-time, data sets or to perform more in-depth analyses of a problem on-board 
the spacecraft, and are transferred on magnetic tape to the POCC as communication blocks 
containing CCSDS Version 1 Transfer Frames. Quick-look data products may be used to 
augment the real-time data processed by the POCC to ensure the continued health and 
safety of the TRMM spacecraft and instruments. Quick-look data products requested by 
the POCC are formatted as files of CCSDS packets and transmitted within 2 hours after 
completion of the TDRS acquisition session designated as a quick-look session. 
Production data products may be used to perform trend analyses and to create a mission 
history for the FOT. Production data products are formatted as files of CCSDS packets 
and transmitted once per day when requested. Quick-look and production data products are 
transmitted electronically to the POCC at a rate of 1 Mbps (TBR). If the data received from 
the TDCF do not meet established quality and accounting criteria, the POCC may request 
retransmission of that data as required. 


5.4 TSDIS INTERFACES 

The TSDIS interfaces with the TDCF are provided by the SOCC and the SDAC via 
Nascom II and a GSFC LAN if the TDCF is located at WSC, or via a GSFC LAN if the 
TDCF is located at GSFC. The TRMM instrument team and the TRMM Science Team are 
located at the SOCC, which is responsible for instrument monitoring and coordination and 
science planning. The SDAC performs higher-level processing (to Levels 1 through 4) of 
the production data products generated by the TDCF. 

The TDCF transmits real-time, quick-look, and production data products to the TSDIS as 
files of CCSDS packets. Real-time packets and associated summary quality and accounting 
information are transmitted at a rate of 200 kbps; quick-look and production data products 
are transmitted at a rate of 1 Mbps (TBR). These data products are distributed to the 
TSDIS SOCC and the TSDIS SDAC in accordance with their current requirements. The 
TSDIS SOCC nominally receives only real-time data products; the TSDIS SDAC nominally 
receives both quick-look and production data products. 

Real-time packets are transmitted immediately upon completion of processing (within 1 
second of receipt) by the TDCF. Quick-look data products are transmitted within 2 hours 
after completion of the scheduled quick-look (TDRS) acquisition session. Production data 
products are transmitted once daily, within 24 hours after receipt of the last bit of data 
comprising the production primary data set. The TSDIS may request retransmission of 
data products received from the TDCF if the quality of the initial transmission is 
unacceptable. 


5.5 FDF INTERFACE 

The FDF interface with the TDCF is accomplished via either Nascom II and a GSFCLAN 
or via a GSFC LAN (for electronic transmission), depending on the location of the TDCF. 
Non-electronic transmission using a physical medium such as a magnetic tape is also an 
option for the FDF interface to the TDCF. Ancillary data products are sent to the FDF for 
refinement or repair and to calculate definitive orbit and attitude and their related parameters 
for subsequent uplink to the spacecraft. Ancillary data are assumed to be downlinked from 
the TRMM spacecraft in packets having an APID unique to ancillary data. Ancillary quick- 
look and routine production data products are formatted as files of CCSDS packets and sent 
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to the FDF as scheduled. Quick-look data products are transmitted within 2 hours after 
completion of the scheduled quick-look (TDRS) acquisition session. Production data 
products are transmitted once daily, within 24 hours after receipt of the last bit of data 
comprising the production primary data set. A data rate of TBD Mbps is assumed for an 
electronic interface; specifications for the non-electronic interface medium are those se 
forth in the FDF Interface Control Document (9-track, 1600- or 6250- bits per inch (bpi), 
unlabeled volume magnetic tapes). If the quality of the initial transmission is unacceptable, 
the FDF may request retransmission of the data from the TDCF. 


5.6 JAPANESE INTERFACE 

The baseline Japanese interface with the TDCF is provided by a desipated data reception 
node on the west coast of the United States. For the purposes of this ^y^eNSGW 
located at the Jet Propulsion Laboratory (JPL) is assumed to be the designated JDRN. The 
TDCF transmits production data products to the JDRN via Nascom n facilities on a daily 
basis The data products are formatted as files of CCSDS packets and are assumed to » be 
transferred at a rate of 1 Mbps (TBR). If the quality of the initial transmission to -the JDRN 
is unacceptable, retransmission of the dat a m ay be requested from the TDCF 1 he possible 
requirement for the TDCF to transmit additional data products to the JDRN is subject to 
future negotiations and is not considered here. 


5.7 DSN INTERFACE 

The DSN interface with the TDCF is provided by the DSN Ground Communications 
Facility (GCF), located at JPL in Pasadena, California, via the Nascom II Network. The 
DSN acts as a backup to the SN, performing the functions required to support the space-to- 
ground link and the transfer of the retur n lin k data stream to the TDCF in the event ot a 
catastrophic failure of the SN. 

The JPL GCF receives the TRMM return l ink data stream from space and transmits the data 
to the JPL NSGW for subsequent transmission to the TDCF. The return link data stream is 
comprised of CCSDS Version 1 Transfer Frames and is transmitted at a rate of 2 Mbps 
once per TRMM orbit. 
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6.0 TRMM DATA CAPTURE FACILITY ARCHITECTURE AND 
DESIGN OPTIONS 

This section presents the TDCF architecture and design options. The TDCF provides the 
functions of data capture, level zero processing, and data distribution for TRMM 
instrument science and engineering data and TRMM spacecraft engineering data. Two 
specific implementations are considered for the TDCF: a Packet Processor (Pacor) based 
implementation and a Customer Data Operations System (CDOS) based implementation. 
These implementations are addressed in the subsections that follow. Each implementation 
is described in terms of the system configuration, operations concept, development and 
operating costs, and advantages and disadvantages. 

The system configuration describes the physical architecture and design of the TDCF in 
terms of the supporting system(s). The architecture and design are also represented in 
pictorial form. Characteristics of the external data and control interfaces associated with the 
architecture are presented in tabular form. 

The operations concept describes the TDC F o perations specific to the implementation. The 
operations concept is a direct function of the specific implementation and differs slightly 
from the general concept presented in Section 2 in the manner in which data are routed to 
and from the TDCF. The operations concepts are intentionally limited in scope, beginning 
at the point at which the data are received on the ground and ending at the point at which 
real-time, quick-look, and production data products are distributed to users. Higher-level 
processing of Level Zero products is beyond the scope of this document. 

Development and operating costs are discussed and quantified at a vej 7 high level. Only 
the factors contributing to deltas in the costs associated with each implementation are 
considered: costs that would be equally incurred regardless of the implementation selected 
are not discussed. 

Finally, the advantages and disadvantages of each implementation are discussed. These 
may include ease of implementation, additional capabilities that, while not required, serve 
to reduce TRMM project costs, and others. 


6.1 PACOR-BASED TDCF IMPLEMENTATION 

This section presents the TDCF implementation option that utilizes the Pacor Data Capture 
Facility (DCF) at GSFC. This implementation of the TDCF represents perhaps the most 
conservative approach to satisfying the data capture requirements for the Tropical Rainfall 
Measuring Mission. The basic functionality required is currently available in the existing 
facility. The Pacor DCF was implemented as the first generic telemetry packet processing 
data system at GSFC. The Generic Block Recording System (GBRS), which will be used 
in this implementation to satisfy TRMM raw data storage requirements, supports all data 
capture requirements for Space Telescope (ST) and the Generic Time Division Multiplexed 
(GTDM) DCF as well as Pacor. Since both Pacor and GBRS are multi-user facilities, the 
capacity available to any particular miss io n will be subject to the launch schedule and 
competing mission requirements in the same time frame. As indicated later in this section, 
reasonable assumptions regarding TRMM requirements and other mission loading indicates 
that the existing capacity of both Pacor and GBRS will have to be expanded to meet the 
needs of TRMM. It is expected that only the costs of those upgrades that are unique to 
TRMM will be allocated to the Project. From the perspective of Code 560, which is the 
focus of this study, a limited marginal cost analysis is the most appropriate way to assess 
upgrade and operating costs. This means that costs will be attributed to TRMM if they are 
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incurred to provide marginal (additional) capabilities necessary because Pacor and GBRS 
are supporting TRMM. 

6.1.1 Pacor TDCF System Configuration 

The basic configuration within the end-to-end ground system is driven by the location of 
the Pacor at GSFC. This permits a LAN interface with other elements located at GSFC. 
The interface with the WSC is a long-haul connection. Figure 6-1 presents a Pacor 
implementation of the generic TDCF shown in Figure 1-1. This implementation assumes 
that Nascom II will be available by June 1996, that the WSC NSGW will have the 
capability to interface directly to the WSGT and STGT, and that Nascom II will support 
both 4800-bit Nascom blocks and any other ground transfer frame that may be accepted to 
extend compatibility with CCSDS Recommendations. 

Under normal operations, all return link data will enter the ground system through the 
WSGT or the STGT. The functional capacity of the Pacor will permit it to utilize data as 
directly received by the WSGT/STGT. The Nascom II will provide connectivity from the 
WSC to the GSFC NSGW. The GSFC NSGW will have a direct interface with the Pacor 
and the POCC to transmit all return link data for processing. The Pacor will use existing 
interfaces with the institutional facilities, namely the FDF, the POCC, and the NCC. 
Coordination with the NMCC and transmission of TDCF data products to the TSDIS will 
be accomplished using GSFC LAN facilities. 

Production data products will be delivered to the Japanese data reception node using the 
Nascom II Network. The DSN will provide an emergency backup TRMM Ground System 
entry point in the unlikely event that the normal SN backups are not adequate. The DSN 
will interface with the TDCF through the Nascom II Network. 

A more detailed functional configuration of the Pacor-based TDCF is illustrated in 
Figure 6-2. The complete functionality of the TDCF will be provided by the combination 
of the Pacor and the Generic Block Recording System (GBRS). All return link data 
entering the system will be routed in parallel to both of these systems. The GBRS will log 
and read to tape all incoming raw data. This facility will provide the two-year archival 
function required for all raw data. 

Tables 6-1 A and 6- IB summarize, to the extent they are known, the characteristics of the 
data flows across each external interface specific to the Pacor TDCF implementation shown 
in Figures 6-1 and 6-2. The data characteristics described include data type, format, rate, 
transport medium, and frequency of transmission. 

The Pacor consists of a hardware front end, the Pacor Matrix Switch Subsystem (PMSS); 
the Front-End Processor Pool; and a pair of general purpose computers, all under the 
control of an Operator Console Pool. The current hardware configuration is presented in 
Figure 6-3. The PMSS accepts 4800-bit Nascom blocks either directly or as a playback 
from the GBRS. This subsystem also provides the interface with the NCC. The major 
portion of the processing is performed on the general purpose computers using the Pacor 
DCF software subsystem. The software subsystem is represented functionally in 
Figure 6-2 by the three applicable processing modes: real-time processing (RTP), quick- 
look processing (QLP), and routine production processing (PP). There is no attempt in 
Figure 6-2 to capture the actual software modules or the data flows among the processing 
modules. The interface to the users of the data products is provided by the PMSS. Tape 
products are generated on the main processor for distribution to users or the POCC as 
required. 
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Figure 6-1. TRMM End-to-End System Concept: Pacor Implementation 
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Figure 6-2. Conceptual Pacor TDCF Implementation 


















Table 6- 1 A. Pacor TDCF Exte rnal Interfaces: Data How Characteristics 
from the TDCF to Other Elements 


From 

To 

Data 

Type 

Format 

Data 

Rate 

Transport 

Medium 

Frequency 

TDCF 

NCC 

Post-Event 

Reports 

TBD 

TBD 

LAN 

Per Orbit 

TDCF 

NSGW 

Production 

Files of 
CCSDS 
Packets 

1.0 Mbps 

LAN 

Daily 

TDCF 

NMCC 

Resource Msgs 

TBD 

TBD 

LAN 

As Required 

TDCF 

POCC 

Q/A Alerts 
Raw Data* 
QL* 

Production* 

TBD 

Com Blocks 
Files of 
CCSDS 
Packets 

TBD 

Mag Tape* 
1.0 Mbps* 
1.0 Mbps* 

TBD 

Mag Tape* 

LAN* 

LAN* 

As Required 
Request* 
Schedule* 
Daily* 

TDCF 

SOCC 

(TSDIS) 

RT 

CCSDS 

Packets 

200 kbps 

LAN (X.25) 

Per Orbit 

TDCF 

SDAC 

(TSDIS) 

QL 

Production 

Files of 
CCSDS 
Packets 

1.0 Mbps 
1.0 Mbps 

LAN (X.25) 
LAN (X.25) 

Schedule 

Daily 

TDCF 

FDF 

QL* 

Production 

(Ancillary) 

Files of 
CCSDS 
Packets 

TBD* 

TBD 

LAN* 

LAN 

Schedule* 

Daily 

TDCF 

JDRN 

Production 

Files of 
CCSDS 
Packets 

1.0 Mbps 

LAN and 
Nascom II 

Daily 


If requested by destination. 
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Table 6- IB. Pacor TDCF External Interfaces: Data Row Characteristics 
from Other Elements to the TDCF 


From 

To 

Data 

Type 

Format 

Data 

Rate 

Transport 

Medium 

Frequency 

DSN 

TDCF 

Return Link 
Data 

CCSDS 

Transfer 

Frames 

2.0 Mbps 

Nascom II 

Per Orbit 

JDRN 

TDCF 

Retx Req 
(Prod) 

TBD 

TBD 

Nascom II 

As Required 

FDF 

TDCF 

Retx Req 
(QL*, Prod) 

TBD 

TBD 

LAN 

As Required 

SDAC 

(TSDIS) 

TDCF 

Retx Req 
(QL, Prod) 

TBD 

TBD 

LAN (X.25) 

As Required 

SOCC 

(TSDIS) 

TDCF 

Retx Req 
(RT) 

TBD 

TBD 

LAN (X.25) 

As Required 

POCC 

TDCF 

Tx Req (Raw*, 
QL*, Prod*) 
Retx Req 

TBD 

TBD 

TBD 

TBD 

LAN 

LAN 

As Required 
As Required 

NMCC 

TDCF 

Resource Msgs 

TBD 

TBD 

LAN 

TBD 

NSGW 

TDCF 

Return Link 
Data (from SN 
or Retx Req) 

CCSDS 

Transfer 

Frames 

2.0 Mbps 

Nascom II 

Per Orbit or 
Retx Req 

NCC 

TDCF 

TDRS 

Schedule 

NCC 
Schedule 
Msg 94 or 99 

TBD 

LAN 

Daily or As 
Required 

WSGT/ 

STGT 

TDCF 

Return Link 
Data 

CCSDS 

Transfer 

Frames 

2.0 Mbps 

Nascom II 

Per Orbit 


*If requested by destination. 
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Figure 6-3. Current Paeor Hardware Configuration 






The GBRS consists of three identically configured computer systems, each of which is 
independently capable of satisfying all of the processing requirements of the GBRS 
mission. During normal operations, two of the systems are in data capture mode and the 
third is in standby mode. Functions provided include data capture, log replay, data 
management, log tape generation, transmission of data to users, and status collection and 
reporting. The components of each computer system include the block recording computer 
(BRC), three front-end processors (FEPs), an output processor (OP), and a Sun 
Microsystems workstation (W/S). The FEPs interface with Nascom lines to receive the 
raw telemetry data from the SN or DSN. The FEPs, BRC, and OP interface to an Ethernet 
LAN to communicate with the W/S. Three high-speed data interfaces (HSDs) are used to 
input data to the BRC from the FEPs; a fourth HSD is used to output data to user facilities 
via the OP. Figure 6-4 provides a block diagram of the GBRS components. 

6.1.2 Concept of Operations for the Pacor TDCF 

The TDCF in this configuration is schedule driven and available for the reception of data 24 
hours a day. It receives TDRSS schedule information from the NCC and is operationally 
prepared for the acquisition session. In the case of RTP it establishes communications with 
the requesting user several minutes before the start of the acquisition session. A post-event 
report is returned to the NCC after each acquisition session to provide reception 
confirmation and quality assessment. 

It is assumed that the return link data stream is carried from the WSC to GSFC by 
Nascom II in standard 4800-bit blocks and that the Pacor will maintain the same functional 
Nascom interface it currently supports, synchronizing on the blocks and disassembling 
them into CCSDS Transfer Frames. The only differences from current operations will be 
that the interface will be at the GSFC NSGW and that an appropriate LAN or dedicated 
local line will provide the NSGW connectivity with the Pacor. 

The return link data stream comprises real-time, playback, and fill data. The real-time data 
are contained in a separate virtual channel which is interleaved with the fill virtual channel 
and one or more playback virtual channels. Upon completion of error checking and 
correction and the separation of the virtual channels, the data are processed as required for 
the several users. 

The two principal users of TDCF production data products are the TSDIS SDAC and the 
Japanese collaborators in the TRMM. Both of these users receive production data products 
on a regularly scheduled basis. It is expected that these production data products will 
include all instrument and spacecraft data packets. The distribution to the Japanese is 
accomplished by entering the processed data into Nascom II at the GSFC NSGW for 
transmission to Nascom II's International Gateway at JPL. The Japanese will provide an 
interface at that location for further distribution to their user community. The distribution to 
the TSDIS SDAC is performed using a LAN. 

A limited subset of the production data, specifically packets containing ancillary data, will 
be provided to the FDF for orbit and attitude calibration, verification, and analysis. It is 
also expected that on a limited, as-required basis, production engineering and housekeeping 
data will be provided to the POCC to analyze spacecraft performance. Data products 
provided to the FDF and the POCC will normally be delivered via a LAN interface, but tape 
media may be used. 

The Pacor-based TDCF also supports the requirement for quick-look processing. In the 
quick-look mode, the data from a single acquisition session is grouped and processed for 
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Figure 6-4. GBRS Block Diagram 





















distribution within two hours of receipt of the last bit of data in the session. Real-time data 
and playback data are not merged. The normal procedure is to use only playback data. The 
primary user for this processing mode is the TSDIS SDAC, which has introduced a 
requirement for three quick-look acquisition sessions per day. It is expected that the FDF 
may require limited amounts of quick-look processing for monitoring sensors and offering 
calibrations. It is also assumed that the POCC may require a limited amount of quick-look 
engineering data for problem analysis and monitoring. 

The third processing mode supported by the Pacor is real-time processing. In this mode, 
the primary data set includes all real-time packets having a specified APID that are received 
during a single acquisition session. As with quick-look processing, there is no merging of 
real-time and playback data. The data are processed on the fly and the packets are received, 
reassembled and sent to the user within 1 second rather than being prepared by the data 
grouping subsystem. The primary user of the real-time processing capability is the TSDIS 
SOCC, which has requested up to 16 acquisition sessions per day in support of instrument 
monitoring and coordination. The average number of acquisition sessions requiring real- 
time processing will probably be considerably less than the peak requirement. 

Data processed in any of the three modes are normally delivered through electronic 
transmissions. Since nearly all of the users of the TDCF data products are located at 
GSFC, it is expected that the interface will utilize a GSFC TAN that permits an X.25 
interface. The Data Distribution Facility (DDF) at GSFC may be utilized for TRMM in this 
time frame. Although it is expected that in the 1996-2000 time frame electronic transfer 
will be the norm both in the primary and backup modes, the proximity of the user systems 
at GSFC will permit the use of physical media such as magnetic tape as a last resort. If 
required by the POCC, raw telemetry data captured by the GBRS at the communication 
block level will be sent to the POCC. 

The Pacor TDCF implementation has several recovery mechanisms should there be 
inadvertent loss of data. The GBRS will record all incoming data streams in parallel with 
the Pacor. If data is lost in the Pacor or a regeneration of data is required, the tapes at the 
GBRS can be replayed and received electronically at the Pacor. If a ground transmission 
failure prevents the capture of data by either of these systems, the LOR at White Sands can 
be utilized for data recovery during the first 5 hours after the initial transmission. If the 
return link data have been contaminated on the spacecraft or during the downlink, a 
retransmission request can be initiated through the POCC. This retransmission request 
must be made within approximately one hour of the original transmission to avoid 
overwriting the data on-board the spacecraft. Finally, data loggers within the Pacor record 
the output production products and retain them for 30 days to permit retransmission to the 
users as necessary. 

6.1.3 Development and Operating Costs 

A comparison of the functional requirements in Section 3 with the capabilities of the Pacor- 
based system indicates that all of functional requirements can be met. Performance 
requirements may pose a significant problem, however. As indicated in the introduction to 
this section, Pacor and GBRS are institutional service facilities and their ability to support a 
given mission depends not only on existing capabilities but also on previous commitments 
to other missions. With the uncertainty in schedules it is difficult to predict just what the 
mission load will be in approximately 7 years when the system will be required for TRMM. 

With regard to the Pacor, the current throughput processing rate is inadequate even when 
neglecting the load of other missions completely. The results of a system performance 
analysis conducted by Computer Sciences Corporation (CSC) in September 1988 indicate 
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an ingest rate of 3 to 3^5 Mbps. For the single channel input of TRMM, the rated capacity 
is adequate to meet the requirement. The continuous processing throughput rate of all 
production and quick-look processing is 100 kbps, or only about 40% of the TRMM 
requirement. These ingest and throughput figures are expected to increase before the 1997 
time frame, however. Currently scheduled upgrades to the Pacor will significantly increase 
the ingest rate and throughput capacity. The ingest rate after these upgrades are operational 
is estimated to be between 4 and 8 Mbps, or 200% to 400% of the TRMM requirement. 
The average throughput after the upgrades are operational is estimated to be 150 kbps, or 
about 62% of the TRMM requirement. 

The missions that are currendy scheduled for the Pacor include: Gamma Ray Observatory 
(GRO) which has a ten-year mission life and will therefore continue to impose 
requirements in the 1997 time frame; Solar and Heliospheric Observatory (SOHO), whose 
nominal mission life extends to August 1997 and will at a minimum impact testing and 
probably early TRMM orbits; 6 or 7 Small Explorer (SMEX) missions, of which perhaps 3 
will be active in 1997; and Extreme Ultraviolet Experiment (EUVE) and its successor X- 
Ray Timing Experiment (XTE), at least one of which will be active in 1997. Orbiting Solar 
Laboratory (OSL) may require Pacor support, however, it will probably be supported by 
CDOS and will not be not considered her£. The minimum mission load at TRMM launch 
in 1997 before considering TRMM requirements and based on current schedules and 
assignments would therefore include at least 6 missions with the estimated data rates 
presented in Table 6-2. A rate characteristic of the continuous real-rime data acquisition 
mode of SOHO has been used to approximate the more severe impact this mission could 
have. 

There are some uncertainties associated with the mission profile assumed for the facility, 
the most significant being the assumed extension of SOHO, with its maximum data rate of 
approximately 245 kbps, into the TRMM operational window. In any case it is clear that 
the Pacor with TRMM will be oversubscribed at least in terms of processing throughput. 

The prudent approach is to assume that Pacor will have to be further upgraded to support 
TRMM, consistent with current planning, and that the upgrade will be sized to satisfy all of 
the TRMM requirements including a minimum contingency capability. It is further 
assumed that at some time in the future the function of Pacor will be assumed by CDOS or 
some other advanced facility. This would dictate that the upgrade should follow a 
minimum cost approach based only on the TRMM mission lifetime since the upgrade may 
not be used for further future missions. 

With these assumptions, the scenario that suggests itself is one in which there is no 
significant change in the hardware and software architecture. The increased capability 
would be obtained by hardware upgrades that will have minimal impact on the software and 
external interfaces. To perform an analysis of this approach it will be necessary to assume 
a processing model that identifies the driving performance requirements and establishes 
estimates of capacity needs. 

As discussed in Section 6.1.1, the GBRS will receive and log all incoming data in parallel 
with the Pacor. The projected Pacor loading of Table 6-2 will thus also impact the GBRS. 
In addition, the GBRS will be supporting additional TDM missions in this time frame. A 
review of GBRS design documentation and discussions with the GBRS Project Manager 
indicate that GBRS will also have to be upgraded to support TRMM due to the relatively 
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Table 6-2. Estimated Pacor Mission Support Requirements, 1996-2000 


Mission Support Estimates 

Estimated 

Average 

Processing 

Rate 

(kbps) 

Peak Ingest 
Rate 

(kbps) 

Possible Mission Profile 



GRO 

32 

512 

SOHO 

245 

245 

SMEX(N) 

10 

56 

SMEX(N+2) 

10 

56 

SMEX(N+2) 

10 

56 

XTE 

32 

512 

Projected Total Pacor Loading (Without TRMM) 

339 

1437 

TRMM Nominal Mission Load 

200 

2000 

TRMM Contingency Requirement 

40 

400 

Projected Total Pacor Loading (With TRMM) 

579 

3837 

Working Estimate of Pacor Projected Capacity 

150 

8000 

(Assuming Currently Scheduled Upgrades) 


i 

Excess (+) or Deficiency (-) of Capacity Over Load 

-429 

+4163 


high ingest rate and data storage volume. A loading study is currently being conducted by 
GSFC to determine the required capacity of the upgrade. At the time this report was 
written, the GBRS upgrade strategy had not been finalized, precluding any authoritative 
estimation of the associated marginal development or operating costs. The GBRS marginal 
development and operating costs are not considered in the remainder of this section. When 
data becomes available upon completion of the GBRS loading study, any marginal costs 
attributable to TRMM should be considered. 

6.1. 3.1 Development Costs 

If the Pacor system is to meet the minimum requirements for throughput identified in 
Table 6-2 it will be necessary to more than triple the currently estimated available capacity. 
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The requirements impose an additional 20% contingency capability on the system. In a 
multi-user environment, it is not necessary that the system design consider a 
worst/worst/worst situation so that the contingencies for each user need not be summed, 
is necessary however, that the total contingency be at least equal to the largest single 
contingency ’ Although the other contingencies are not known, a reasonable assumption is 
tha t t hl TRMM contingency will be the largest. A 20% contingency has been noted in 
Table 6-2. The total required increase in capacity would correspond to an additional 
throughput processing capability of approximately 429 kbps continuously. 

At this time there is only limited information available regarding the total system loading 
that results from imposing a requirement to process a given telemetry scream. Studies are 
currently in progress to assess this issue for both operating cost estimates and futu 
development planning. In order to perform such a loading study, the software must be 
understood and evaluated and any unique features of the hardware such as special function 
processors must be understood. It is outside of the scope of this study to perform such a 
SSSS £ ™sis and is probably not necessary for the TRMM mission unul other issues are 
resolved. For purposes of this study a more general estimate of cost is sufficient. 

It is valuable to identify the most significant parameters that characterize the c 
work load generated by a processing requirement. Certainly the most important is the 
number orbits that must be processed. In addition, because of the nature of the 
processing the number of packets or the average size of the packets will impact the 
processing'loading. Since the data must be captured at the telemetry rate and stored or 
processed, the telemetry rate will certainly impact hardware configuration and, from a cost 
perspective, the impact may be greater than linear. The processing modes (real-time, 
quick-look, production) required to support a mission will have an effect and the nature ot 
the distribution of data products will certainly affect operating cost. 

For purposes of this study, it is assumed that the TRMM data stream is similar to that 
assumed for the current throughput capacity and the estimated capacity of the planned 
updates. Under this assumption, the additional 429 kbps net average throughput 
requirement means that it will be necessary to more than triple the capacity of the main 
processors as configured for the upgraded Pacor. 

As stated earlier, the recent (June 1990) redefinition of CDOS strongly suggests that the 
CDOS facility will at some point assume the mission loads that might have otherwise gone 
to Pacor In this environment the most reasonable way to address any Pacor upgrade 
associated with TRMM is to assume that the upgrade will not provide service beyond the 
TRMM mission and that the life cycle cost for the upgrade will be limited by the TRMM 
mission life. This will have the impact of increasing the importance of any development 
costs. In particular, there must be strong justification for redevelopment of any software. 
In the case of the Pacor software, approximately 37% of the code is written in assembly 
language and another 15% is written in Template, a special display language. Thus a 
significant portion of code could not be ported easily. If redevelopment of the software is 
to be avoided it may be necessary to obtain hardware with the same instruction set so that 
the optimized machine language portion does not have to be changed. 

Unless hardware can be identified that increases by a factor of roughly 5 the present system 
processing capability, it will be necessary to acquire a separate processor, shanng any 
components that can be shared and run in parallel with the existing system. There are 
definite reliability advantages to having such parallel systems but there may also be 
additional operating costs. For present purposes it is assumed that the P^allelsystem 
approach will be implemented, that modifications planned for the PMSS and other front 
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end elements can be shared, and that the projected ingest rate of 8 Mbps will be supported 
by these front end elements. 

The Pacor system is currendy using ENCORE 32/9750 hardware for the packet processor 
computers. The simplest upgrade path would be to obtain instruction- set-compatible 
hardware with more processing power. It is our understanding that the ENCORE 
Concept 32/2000 hardware would provide the compatible instruction set with increased 
computational power. Clearly this upgrade path is not the only one, and if hardware costs 
become too large the cost and risk of breaking or losing the software may become the 
cheaper alternative. This may be particularly true in light of the availability of new special- 
purpose hardware. There may be other alternative hardware suites that would provide the 
same compatibility and these should be explored. The compatible instruction set approach, 
however, should be the first explored and used as a baseline for other alternatives. 

Based on budgets associated with the current upgrades, the cost of hardware procurement, 
installation, and test are estimated to be on the order of $4.5 to $5.9 Million. These 
numbers assume a configuration in which three new higher-capacity processors will be 
installed, two to replace the existing machines and a third string to provide a new second 
operational capability. Figure 6-5 is a conceptual diagram of the Pacor hardware 
configuration upgrade. One of the processors will provide backup for the other two 
operational units. In order for the upgrade to be up and functional for testing 9 months to 1 
year before launch, the procurement will have to be made in FY94. The cost will be a 
strong function of the peripherals required to support the mission in addition to the 
configuration of the main processor. 

6. 1.3.2 Operating Costs 

Because the Pacor upgrade required to support TRMM is assumed to consist of a separate 
processing equipment string, additional operator support may be required specifically to 
handle that system. The cost of that support requirement would need to be considered as 
an additional operating cost of the Pacor. For budget planning purposes. Code 560 has 
developed operating cost estimates based on operations as a dedicated TRMM facility. The 
major cost element in this estimate is the labor cost for 3 shifts per day of operators, 
analysts, systems engineers and supervisors. Equipment maintenance contracts have been 
assumed for the processors and related equipment. Facilities costs unique to the TRMM 
operation, including expendables and service charges, are included. The costs incurred 
during the prelaunch testing period and the post-operational period range from $300K to 
$500K per year. During the 3-year operational period, the costs are estimated to be 
approximately $1 Million pd:year. For the assumed 5-year period ( including prelaunch 
testing, mission operations, and post-mission operations), the average cost is estimated to 
be approximately $800,000 per year. 

While the estimation of operating costs for a dedicated facility is relatively straight-forward, 
there is currently no algorithm available to allocate proportionate shares of operating costs 
in the Pacor multi-user environment. It can reasonably be assumed, however, that there 
would be a significant reduction in operating costs in a multi-user environment. An order 
of magnitude estimate might place the shared cost for TRMM at less than $500,000 per 
year during the flight operations period. It is understood that there is a study in process to 
provide such an algorithm for resource planning purposes. 

The communication links necessary to support the distribution of data to and from the 
Pacor-based TDCF will be provided by Nascom/Nascom II as an institutional resource. 
The requirements to support the Pacor implementation include a 2 Mbps link between WSC 
and the GSFC NSGW as the primary return link channel. Since the POCC will handle all 
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operations data and since the NSGW will not separate the virtual channels, the POCC will 
need a 2 Mbps local link to the NSGW. The Pacor will also require a local 2 Mbps link to 
the NSGW to obtain the return link data stream. A 1 Mbps (TBR) LAN will distribute 
processed data to the TSDIS and other local GSFC users. A 1 Mbps (TBR) long-haul link 
will be needed to transmit production data products to the JDRN assumed to be located at 
JPL. The relative costs of these communications links are discussed in the cost trade-off 
presented in Section 7.1.2. 

6.1.4 Advantages 

The primary advantages associated with the Pacor implementation result from two key 
features of the system. First, even though the Pacor is an institutional facility, the upgrades 
required to support this mission will permit much of the customization that would result 
from a dedicated facility. Second, the facility would be collocated with all of its users with 
the exception of the Japanese users. Both of these features would permit more effective 
mission development and operation. The Pacor option represents a minimum development 
risk choice since existing capabilities would serve as die basis for any upgrades and a 
significant measure of local visibility and control would increase development schedule 
reliability. 

6.1.5 Disadvantages 

The disadvantages of the Pacor implementation result most significantly from the relatively 
small scale of the Pacor operation. The current system would not be able to handle the 
TRMM return link ingest rate or the aggregate throughput rate. Thus there would clearly be 
development costs incurred to upgrade the system. The exact system load imposed by 
TRMM becomes much more significant because the TRMM mission would be a large part 
of Pacor's total work load. In addition, with a smaller operation, contingency capabilities 
become more expensive since there is less statistical sharing of t he contingency among 
missions. There is still some concern that existing software would function properly on a 
new host. Finally, if the actual load on Pacor is significantl y greater than projected due to 
increases in TRMM requirements (considered to be a low probability) or to a larger-than- 
expected load from other missions during the TRMM mission, Pacor would not be easily 
expandable to meet such additional load. 


6.2 CDOS-BASED TDCF IMPLEMENTATION 

The CDOS implementation of the TDCF provides nearly all of the required functionality 
described for the TRMM ground system in the general implementation scenario presented 
in Section 2. The system configuration and operations concept described in the paragraphs 
that follow were developed on the basis of the CDOS Level II Requirements Document 
(CDOS 202.0002 V3 Review Copy, July 12, 1990), the CDOS Operations Concept 
Document (CDOS 0106.0002 V7, Draft, June 1990), and the current CDOS architecture. 

6.2.1 CDOS TDCF System Configuration 

The CDOS implementation of the TDCF in the TRMM end-to-end system concept is 
illustrated in Figure 6-6. Communication links are largely provided by the Nascom II 
Network. Figure 6-7 illustrates a more detailed functional configuration of the CDOS- 
based TDCF. Tables 6-3A and 6-3B summarize the data flow characteristics of the logical 
and physical interfaces between CDOS and applicable external entities and networks. The 
data flow characteristics described include data type, format, rate, transport medium, and 
frequency of transmission. 
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Figure 6-6. TRMM End-to-End System Concept: CDOS Implementation 










WSGT/STGT 
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Figure 6-7. Conceptual CDOS TDCF Implementation 










Table 6-3A. CDOS TDCF External Interfaces: Data Flow Characteristics 
from the TDC F to Other Elements 


From 

To 

Data 

Type 

Format 

Data 

Rate 

Transport 

Medium 

Frequency 

TDCF 

NCC 

Post-Event 

TBD 

TBD 

Nascom II / 

Per Orbit 


Reports 
LOR Retx 
Req 

TBD 

TBD 

LAN 

Nascom 11/ 
LAN 

As Required 

TDCF 

NSGW 

Production 

RT 

QL 

Files of 
CCSDS 
Packets 

1.0 Mbps 
1.0 Mbps 
1.0 Mbps 

Direct Wire 
Direct Wire 
Direct Wire 

Daily 

Schedule 

Schedule 

TDCF 

NMCC 

Resource 

Msgs 

TBD 

TBD 

Nascom 11/ 
LAN 

As Required 

TDCF 

POCC 

Q/A Alert 
Raw Data* 
QL* 

Production* 

TBD 

Com Blocks 
Files of 
CCSDS 
Packets 

TBD 

Mag Tape* 
1.0 Mbps* 
1.0 Mbps* 

TBD 

Mag Tape* 
Nascom 11/ 
LAN* 

As Required 
Request* 
Schedule* 
Daily* 

TDCF 

SOCC 

(TSDIS) 

RT 

CCSDS 

Packets 

200 kbps 

Nascom 11/ 
LAN 

Per Orbit 

TDCF 

SDAC 

QL 

Files of 

1.0 Mbps 

Nascom IV 

Schedule 

(TSDIS) 

Production 

CCSDS 

Packets 

1 .0 Mbps 

LAN 

Daily 

TDCF 

FDF 

QL* 

Production 

(Ancillary) 

Files of 
CCSDS 
Packets 

TBD* 

TBD 

Nascom IV 
LAN 

Schedule* 

Daily 

TDCF 

JDRN 

Production 

Files of 
CCSDS 
Packets 

1.0 Mbps 

Nascom II 

Daily 


*If requested by destination. 
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Table 6-3B. CDOS TDCF External Interfaces: Data Flow Characteristics 
from Other Elements to the TDCF 


From 

To 

Data 

Type 

Format 

Data 

Rate 

Transport 

Medium 

Frequency 

DSN 

TDCF 

Return Link 
Data 

CCSDS 

Transfer 

Frames 

2 Mbps 

Nascom II 

Per Orbit 

JDRN 

TDCF 

Retx Req 
(Production) 

TBD 

TBD 

Nascom II 

As Required 

FDF 

TDCF 

Retx Req 

(QL*, 

Production) 

TBD 

TBD 

LAN/ 
Nascom II 

As Required 

SDAC 

(TSDIS) 

TDCF 

Retx Req 
(QL, 

Production) 

TBD 

TBD 

LAN/ 
Nascom II 

As Required 

SOCC 

(TSDIS) 

TDCF 

Retx Req 
(RT) 

TBD 

TBD 

LAN/ 
Nascom II 

As Required 

POCC 

TDCF 

Tx Req 
(Raw*, QL*, 
Prod*) 

Retx Req 

TBD 

TBD 

TBD 

TBD 

LAN/ 
Nascom II 

LAN/ 
Nascom II 

As Required 
As Required 

NMCC 

TDCF 

Resource 

Msgs 

TBD 

TBD 

Nascom II 

TBD 

NCC 

TDCF 

TDRS 

Schedule 

NCC 
Schedule 
Msg 94 or 99 

TBD 

LAN/ 
Nascom II 

Daily or 
As Required 

WSGT/ 

STGT 

TDCF 

Return Link 
Data 

CCSDS 

Transfer 

Frames 

2 Mbps - 

Direct Wire 

Per Orbit 


If requested by destination. 
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The Data Delivery Element (DDE), located at the CDOS DIF, provides the functionality 
specified in the CDOS Level II Requirements Document for the Data Delivery Service and 
for the Archival Data Management Service, Applicable TDCF functions include data receipt 
and capture, R-S emor decoding and correction, virtual channel separation, packet 
demultiplexing, real-time, quick-look and production data processing, data quality 
assessment and accounting, short-term storage of routine production data products, and 
distribution of both unprocessed data streams and processed data products. 

Data are routed from the DIF to their intended destination(s) by means of the Nascom II 
Network. The data rate to each destination is the rate previously established by negotiation 
between CDOS and the destination. CDOS will rate convert the data as required to provide 
the desired data transmission rate to the destination. 


6.2.2 Concept of Operations for the CDOS TDCF 


CDOS operates primarily as a table- and data-driven system. The DDE operates as an 
active service in that it is continuously ready to receive data. Scheduling information is not 
required to process or deliver the data, since processing and delivery requirements are 
established during the pre-mission phase. These requirements may be modified if 
necessary during operations through negotiation with the CDOS Operations Management 
Service. Physical reconfigurations of the system are not required under normal 
circumstances. 

In the CDOS TDCF implementation, the return link data stream is routed from the 
WSGT/STGT directly to the CDOS DIF collocated at the WSC. A signalling protocol is 
used to verify the operational readiness of the interface between the WSGT/STGT and the 
DDE. The DDE receives the return link data stream from the WSGT/STGT, performs any 
required error checking and correction, and separates the physical data stream into its 
component virtual channels. The fill virtual channel is discarded. . The real-time and 
playback virtual channels are captured on some kind of physical medium and stored for a 
period of 20 years. Quality and accounting information is generated for each real-time and 
playback virtual channel. 

All real-time and playback data and data products are routed to their destination(s) using 
Nascom II facilities. If required by the data destination, the DDE demultiplexes packets 
from the virtual channels. The DDE transmits the virtual channels and packet channels to 
the NSGW collocated at the DIF (the WSC NSGW). Multiple channels bound for a single 
destination are multiplexed by the NSGW prior to transmission over the long-haul links. 

Real-time CCSDS packets are immediately routed to the POCC for use in monitoring 
spacecraft and instrument health and safety. Real-time packets and their associated data 
quality and accounting summary are transmitted to the POCC at a rate of 200 kbps, die rate 
at which the data are received by CDOS, in order to minimize the delay incurred. The 
POCC is required to perform any additional packet processing required to support health 
and safety monitoring. 

Real-time and playback packet streams receive additional processing by CDOS in 
accordance with negotiated user requirements. The data are identified as requiring real- 
time, production, or quick-look data processing on the basis of current data processing 
parameters associated with each packet channel (e.g., APID). 

Real-time processing provides summary quality and accounting information for real-time 
packets received during a single TDRS acquisition session having the specified APID(s). 
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The real-time packets and summary quality and accounting information are transmitted to 
the TSDIS SOCC for instrument operations and science planning. Each real-time packet is 
transmitted upon completion of the necessary processing; the quality and accounting 
summary is transmitted upon completion of processing of the last real-time packet 
comprising the primary data set. 

For data requiring routine production processing, the DDE reconstructs instrument and 
spacecraft data sets, merging real-time and playback data, time-ordering the data, removing 
redundant data packets, identifying gaps in the data, and annotating the data with 
appropriate quality and accounting indicators. The resulting production data products are 
transmitted to a data store to be staged and formatted for distribution to users. Data 
distribution is accomplished by the DDE via Nascom II facilities. Production data products 
are delivered to users within 3 hours nominal, 21 hours maximum, of receipt of the last bit 
of data comprising the primary data set by CDOS. Production data products containing 
science, engineering, and ancillary data are distributed to the TSDIS SDAC for higher-level 
processing (Levels 1 through 4) and to Japanese users. 

Quick-look processing is also performed by the DDE. Quick-look processing is identical to 
routine production processing with a few exceptions. Quick-look processing uses only 
playback data, i.e., it does not merge real-time and playback data or provide redundant data 
removal. In addition, quick-look primary data sets are bound by a single TDRS acquisition 
session. Quick-look data products are delivered to users within 10 minutes of receipt of the 
last bit of data comprising the quick-look primary data set by CDOS. Quick-look science 
and engineering data products are distributed to the TSDIS SDAC for science coordination. 

Ancillary data are processed in both the quick-look mode (if scheduled) and the routine 
production mode. The resulting data products are transmitted to the FDF for definitive 
orbit processing and analysis. (Definitive data products are transmitted to the TSDIS by the 
FDF for use in higher-level processing.) 

Quick-look and production data products transmitted to users over electronic media use 
protocols that support computer- grade communication error rates and "registered delivery". 
Two delivery options are available. In the first option, users are notified when their data 
products are ready. The users then notify CDOS to establish a session for delivery of the 
data products. In the second option, data products are transmitted upon completion of 
processing and establishment of a signalling protocol with the user. Production data 
products may also be delivered on a scheduled basis. 

Quick-look and production data products are transmitted using a File Transfer, Access and 
Management (FTAM) protocol at a rate of at least 1.5 times the average instrument data 
generation rate. Data products are stored until users confirm receipt. Users are given an 
inventory of their data products residing in the DDE to use in accounting for their data. 

If the quality and accounting data generated by the DDE indicates that the quality of the 
return link data is unacceptable, CDOS will alert the POCC. Processing and delivery of the 
current data will continue. Since CDOS receives the data directly from the WSGT/STGT, 
retransmission of the data for reasons other than line (interface) outage or a catastrophic 
failure within CDOS must come from the spacecraft. The POCC may request 
retransmission from the TRMM spacecraft within approximately 1.5 hours of the initial 
dump. If a catastrophic failure occurs at the WSGT/STGT - CDOS interface, the data may 
be recovered from the WSGT/STGT LOR for up to 5 hours after the initial dump. 

Users requiring retransmission of captured data may obtain that data from CDOS in either 
of two ways: electronically from CDOS, if an electronic interface exists between the user 
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and CDOS; or on a physical medium if n o el ectronic interface exists. If the data requested 
are currently contained in the on-line data base and the user has an electronic interface to 
CDOS, retransmission is accomplished simply by a line replay of the requested data. If the 
data are currently contained in the on-line data base and the user does not have an e ectromc 
interface to CDOS, a tape or disk is generated and sent to the user If the desired data do 
not reside in the on-line data base, they must be recovered from the off-line archive and 
replayed electronically or used to generate the appropriate physical media. 


Users requiring retransmission of production data products generated by CDOS may obtain 
them from CDOS via an electronic interface at any time within the 7-day storage penoa. 
Production data product retransmissions requested after the 7-day period must be either 
reprocessed from raw (captured) data (negotiated with CDOS on an individual basis) or 
recovered from Level 1A data products stored by the TSDIS. 


6.2.3 Development and Operating Costs 

The TDCF requirements presented in Section 3 are compatible with and satisfied by 
existing CDOS requirements. Development costs for a CDOS-based TDCF will therefore 
be inherently borne by the CDOS Project. Operations costs associated with processing 
TRMM data are likewise incurred within CDOS, but should be included in the TRMM 
Project costs to ensure proper budget allocations, since CDOS operating costs are 
reimbursable at the Code S/Code O Level. Communications costs associated with 
delivering TRMM data and data products are direcdy attributable to the TRMM Project. 


6.2.3. 1 Development Costs 

The TRMM- specific development costs associated with the CDOS implementation of the 
TDCF are the costs of integration and test activities attributable to the TRMM mission. 
These costs cannot be quantified at this ti me due to the evolving nature of both TRMM and 
CDOS. 


6. 2. 3. 2 Operating Costs 

Operating costs are assumed to include those incurred for CDOS services. CDOS has not 
yet identified the method by which processing costs will be allocated to users_ A 
preliminary CDOS life-cycle cost analysis providing a rough-order-of-magmtude (ROM) 
estimate for annual operating costs has been developed, but the cost data are procurement- 
sensitive and are not currently available for use in estimating TRMM processing costs. It is 
not clear that CDOS will in fact establish a method to allocate costs to users, since CDOS is 
intended to be an institutional service funded by Code O. A ROM estimate of the TRMM 
processing costs could be derived on the basis of the preliminary life-cycle costs once they 
are made available by assuming that TRMM processing costs would be in some way 
proportional to the volume of TRMM data processed relative to the CDOS data processing 
capacity, and taking into account some percentage of the amortized development costs. 

The communications costs associated with delivering TRMM data and data products to 
users are a function of the volume of data transferred as well as the rat e at which the data 
are transferred. Since the CDOS DIF is c ollocated with the WSGT and STGT at the WSC, 
communications costs are incurred only for the distribution of data products; delivery or the 
raw data to the CDOS TDCF is accomplished via "holes in the wall" at the DIF rather than 
long-haul communications links. The CDOS TDCF data delivery requirements necessitate 
a 1 Mbps (TBR) link from the WSC NSGW to the GSFC NSGW to support the delivery 
of real-time, quick-look, and production data products to users at GSFC; a 1 Mbps ( I BR) 
link from the WSC NSGW to the JP L N SGW to support delivery of production data 
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products to the JDRN; and 1 Mbps (TBR) LAN facilities at GSFC. In addition, two 200- 
kbps links are required — one from the GSFC NSGW to the POCC and one from the 
GSFC NSGW to the TSDIS SOCC -- to permit real-time data delivery. The relative costs 
of these communications links are discussed in the trade-off presented in Section 7.1.2. 

6.2.4 Advantages 

The CDOS-based TDCF implementation offers a number of potential advantages to the 
TRMM Project, including centralized virtual channel separation and packet demultiplexing 
functions and a forward link capability. Use of these services, negotiated as required with 
CDOS, may serve to reduce TRMM Project costs. 

CDOS performs the functions of virtual channel separation and packet demultiplexing at the 
WSC. The centralization of these functions at the WSC reduces the amount of processing 
that must be done by the POCC to obtain the real-time data necessary to monitor spacecraft 
health and safety. The reduction in the amount of processing at the POCC simplifies 
POCC operations and potentially allows a reduction in processing costs to the TRMM 
Project. 

The forward link capability of CDOS provides a reliable and cost-effective means of 
uplinking commands and ancillary data to the TRMM spacecraft. Forward link data may be 
transmitted from TRMM facilities at GSFC to the WSGT/STGT facilities at White Sands 
via the intervening Nascom II facilities and the DDE at the CDOS DEF. The DDE will 
properly format the data into the specified CCSDS protocol and transmit the data to the 
WSGT/STGT. The TRMM Project would incur only the costs of using the CDOS and 
Nascom II services, which is a fraction of the cost of providing those services for a single 
user. For example, instead of leasing a secure Nascom circuit to transmit data from the 
POCC to the WSGT/STGT, the TRMM Project would pay for the use of an existing trunk, 
perhaps shared with other CDOS and Nascom II customers, that provides the required 
connectivity. Interfaces would be simplified and reduced in number since the POCC would 
only interface with CDOS rather than with both CDOS (return link) and WSGT/STGT 
(forward link), and the CDOS DDE would provide the necessary CCSDS formatting and 
synchronization for the uplink. 

6.2.5 Disadvantages 

There are two primary disadvantages to the CDOS TDCF implementation: the location of 
the production data processing function and schedule. 

The current CDOS architecture provides centralized production processing at White Sands. 
Although the long term impact may not be significant, there is an inherent disadvantage to 
this architecture in that the TSDIS SDAC, which receives the Level Zero data products and 
performs higher-level processing, will require an interface to Nascom II facilities that does 
not currently exist. At present, all Level Zero processing is performed at GSFC by the 
IPD. Level Zero data sets are transmitted to the SDAC over existing GSFC LANs. In 
order to receive Level Zero data sets transmitted from White Sands via Nascom II, an 
additional and potentially more complex interface between Nascom II facilities and the 
TSDIS SDAC will be required. 

The primary disadvantage of the CDOS TDCF implementation is the current CDOS 
schedule. The TRMM spacecraft is scheduled for launch in August 1997, and will require 
CDOS support for prelaunch testing in June 1996. The current CDOS schedule provides 
an implementation milestone of First Quarter 1996. If the launch occurs earlier than the 
scheduled August 1997 date, as might happen to accommodate the Japanese launch 
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schedule CDOS would not be available in time to meet testing requirements. In addition it 
is unknown at this time what functions and capacities will be available at the time of the 
fcSstone and hence, whether the CDOS Level Zero processing capabilities required 
bTth^TOMM Project would be available within the TRMM Project schedule consuramts. 
This issue needs to be clearly resolved in order to permit a decision regarding a CDO 
Ssed TOCF .h° schedules can be reconciled, the CDOS TDCF unplementanon offers 
many advantages to TRMM and is the preferred implementanon. 
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7.0 CRITICAL ISSUES AND TRADE-OFFS 

The proposed Pacor and CDOS implementations presented in Section 6 each fulfill the 
TDCF requirements identified in Section 3. The advantages and disadvantages of each 
implementation highlight the critical issues and trade-offs that must be considered in 
selecting the TDCF implementation that best satisfies the Project and Code 560 requirement 
for a cost-effective Level Zero processing capability. These issues and trade-offs include 
cost factors, risk factors, and operational factors as well as other considerations such as the 
appropriateness of certain driving functional and performance requirements. 


7.1 COST FACTORS 

A number of cost factors specific to each TDCF implementation are discussed in this 
subsection. The development and operations cost factors considered are primarily the 
result of the TRMM processing rate and volume requirements relative to the lucr 
implementation processing capabilities. TRM M represents a large customer to the Pacor, 
with an average processing throughput requirement of 240 kbps with contingency as 
opposed to the Pacor's current 100 kbps average processing throughput capacity. 
Conversely, TRMM represents a very small customer to CDOS when considenng CDOb s 
proposed 216 Mbps average processing throughput capacity. 


7.1.1 Development Costs 

Since the current Level II CDOS requirements fully satisfy the functional, performance, 
and operational requirements identified for the TDCF in Section 3, the only additional 
development costs that would be incurred to implement a CDOS-based TDCF are those 
incurred in support of integration and test activities. The Pacor implementation would also 
incur costs in support of integration and test activities. For the purposes of the ffade-ott 
study, the integration and test costs are assumed to be equivalent for both IDCh 
implementations and will not be considered further. 

The existing Pacor facility satisfies the functional and operational TDCF requirements, but 
would need augmentation to meet the performance requirements. The current Pacor 
configuration supports a 3 Mbps to 3.5 Mbps ingest rate and a 100 kbps average 
throughput rate, compared to the TDCF requirements to support a 2 Mbps ingest rate arid a 
240 kbps average processing throughput rate (with contingency). Section 6.1.3 identified 
the most cost-effective approach to modifying the Pacor to satisfy all of the TRMM 
performance requirements as a hardware upgrade in which there is no significant change in 
the hardware and software architecture. This upgrade would entail the purchase ot a 
second redundant equipment string with increased capacity sufficient to handle the specified 
ingest and peak throughput rates. The approximate cost of the upgrade, outlined in Section 
6. 1.3.1, is $4.5 Million. 


7.1.2 Operations Costs 

Operations costs comprise data processing and data communications costs. TTie operations 
costs associated with each TDCF implementation are examined in this subsection. 

The computer operations costs associated with processing the TRMM hnkdata 

stream to Level Zero are assumed to be comparable for both the Pacor and CDOb I DLr 
implementations. Both implementations perform the same type of processing for the same 
data rates and volumes and on the same schedule. However, the Pacor implementation, 
with its TRMM-dedicated processing string, will require additional operations and 
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maintenance personnel whose costs are directly attributable to the TRMM Project. In 
addition, the CDOS implementation may achieve a reduction in the overall TRMM Project 
operations costs by reducing the amount of processing that must be performed by the 
POCC and through economies of scale resulting from the magnitude of the CDOS 
processing capabilities. 

As noted in Section 6. 1.3.2, operating costs have been estimated by Code 560 for the 
Pacor TRMM equipment string and support facilities as a dedicated operation. Operations 
and maintenance personnel, system engineers, and supervisory staff will be required to 
operate and maintain the TRMM-dedicated equipment string. As a starting point, a 
minimum operations staff of 6 would yield an estimated annual personnel cost of 
$300,000. Equipment maintenance contracts for the new string would be an additional 
cost. Operation and support personnel training would be required during the start-up 
period with this cost averaged over the TRMM mission life. A rough order of magnitude 
cost for these operations costs along with contingency would drive the total cost to over 
$500,000. The budget estimate for operations of the new system is approximately $1 
Million per year for each of the three operational years. Prelaunch testing and post-mission 
operations are estimated to cost an additional approximate $1 Million. There is some 
question as to the allocation of such operations costs among mission since such an 
allocation is not performed. It is clear that the bulk of the estimate would be allocable to 
TRMM using the marginal cost approach indicated earlier. For purposes of this initial 
estimate a total annual operating cost of $800,000 will be assumed to be attributable to the 
TRMM for the five-year period (including prelaunch testing, mission operations, and post- 
mission operations). 

In the Pacor implementation, the entire 2 Mbps return link data stream is routed to both the 
Pacor and the POCC at GSFC. The Pacor and the POCC must perform identical virtual 
channel separation and packet demultiplexing functions, with the Pacor then processing the 
data in real-time or in the quick-look or production modes, and the POCC processing only 
the real-time packets. 

In the CDOS implementation, separation of the real-time and playback virtual channels and, 
if required by the user, packet demultiplexing from the virtual channels occurs at the WSC 
immediately after receipt of the return link data stream by the WSGT or STGT and CDOS. 
Real-time data and summary quality and accounting information are transmitted to users, 
including the POCC, within 400 to 600 milliseconds of receipt by the CDOS DIF. This 
capability substantially reduces the amount, and consequendy reduces the cost, of front-end 
processing that must be performed by the POCC to obtain the real-time packets necessary 
to accomplish the POCC's mission to maintain spacecraft health and safety. The POCC is 
relieved of the tasks of separating and identifying the real-time virtual channel and 
demultiplexing and sorting by APID the constituent real-time packets, instead receiving 
packet channels organized by APID that are ready for immediate analysis. The 400 to 600 
millisecond delay imposed by CDOS is comparable to the delay that would be incurred by 
the POCC performing the same functions for the entire return link data stream received 
directly from the WSGT or STGT via Nascom. Operationally, it is more efficient and cost- 
effective to perform the tasks of virtual channel separation and packet demultiplexing at a 
single location rather than at multiple locations. 

The second operations cost component that must be considered in the Pacor versus CDOS 
trade-off is that of communications costs. The Pacor implementation requires a 2 Mbps 
link between the WSC and the GSFC NSGW, a 1 Mbps (TBR) link between the GSFC 
NSGW and the JDRN assumed to be located at JPL, and 1 Mbps (TBR) LAN facilities at 
GSFC. There must also be dedicated 2 Mbps links between the GSFC NSGW and both 


7-2 


the Pacor and the POCC at GSFC to support real-time delivery of the return link data 
stream. 


The CDOS implementation requires a 1 Mbps between and Ae m^^JPL 

the GSFC NSGW, a 1 Mbps (TBR) link between the WSC NSGW and the JDRN at JPL, 
and 1 Mbps (TBR) LAN facilities at GSFC, The CDOS capability to perform centralized 
virtual channel separation and packet demultiplexing at the WSC reduces ; the reqmred 
dedicated link data rate to support real-time data delivery from the GSFC NSGW to t e 
POCC by an order of magnitude, from 2 Mbps to 200 kbps. 

Table 7-1 summarizes the communications links associated with the Pacor and CDOS 
implementations. The 1 Mbps GSFC LAN(s) are assumed to be identical and are not 
shown in the table. For trade-off study purposes, the approximate length in miles of each 
link is presented to permit a qualitative comparison of the costs associated with the • 
The estimation of ROM installation and operations costs associated with the Nascom links 
is a Nascom consideration and beyond the scope of this study. Link redundancy or 
alternate routing necessary to achieve the required link reliability and availability are also 
not considered. 


Table 7-1. Pacor and C DOS TDCF Communications Links 


Communications 

Link 

Miles 

Pacor 
Data Rate 

CDOS 
Data Rate 

WSC - GSFC 

1860 

2 Mbps 

1 Mbps 

GSFC - JPL 

2310 

1 Mbps 

N/A 

WSC - JPL 

865 

N/A 

1 Mbps 

GSFC NSGW - POCC 

0.45 

2 Mbps 

200 kbps 

GSFC NSGW - Pacor 

0.33 

2 Mbps 

N/A 


Based on the data rates and links lengths presented in Table 7-1, the CDOS implementation 
appears to incur approximately one-half of the annual communications costs incurred y 
the Pacor implementation. 


7.2 RISK FACTORS 

There are three risk factors of significance to the Pacor - CDOS TDCF trade-off. 
development schedule, capacity, and operational reliability, maintainability, and 
availability. These factors are discussed in Sections 7.2.1 and 7.2.2. 
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7.2.1 Development Risks 

There are development risks associated with each of the proposed TDCF implementations. 
These development risks are primarily related to schedule and so are of a non-technical 
nature. 

As noted in previous sections, the Pacor implementation will require the acquisition of a 
new equipment string dedicated to Level Zero processing TRMM return link data. This 
new equipment string must be of higher capacity than the existing Pacor equipment strings 
to accommodate the 240 kbps average processing throughput rate. Using the strategy 
suggested in Section 6. 1 , upgrading the hardware with minimal impact on software poses a 
limited risk. The schedule risk is estimated to be low since the hardware is available, 
software modifications should be minimal, and Pacor is a proven system. 

The schedule risk associated with the CDOS TDCF implementation is somewhat greater 
than that associated with the Pacor TDCF implementation. The CDOS Project completed 
its Phase B Architecture Studies in June 1990. The Level III requirements specification is 
still under development at GSFC. The Phase C/D Design and Implementation contract is 
expected to be awarded sometime in 1991; the CDOS implementation schedule is at this 
time only vaguely defined. The TRMM will require CDOS support for prelaunch testing 
no later than June 1996. It is not currently known whether the CDOS Level Zero 
processing capabilities required to support the TRMM will be available within the TRMM 
Project schedule constraints. 

7.2.2 Operations Risks 

The operations risks significant to the TDCF implementation trade-off study are related to 
two issues that deal primarily with Pacor. The first, which represents a minimal risk, is 
that the system availability specification for the Pacor implementation is met because of the 
parallel capture function provided by the highly reliable GBRS. There is no reason for 
concern regarding the primary capture function or loss of data as a result of the GBRS 
reliability. There may, however, be some loss of response-time performance for Pacor 
functions (e.g. real-time processing) unless the Pacor operates in a hot backup mode. The 
Pacor currently operates in a cold backup mode. 

The second issue is associated with the relatively small size of the Pacor relative to CDOS 
and the variability of the load requirements. As our limited analysis indicates, a reasonable 
mission load in the TRMM time frame will stretch the capacity of an upgraded Pacor. If 
additional unanticipated mission requirements are levied on Pacor due to schedule changes 
near to the TRMM launch it may be very difficult to make further unplanned upgrades and 
satisfy all of the requirements. Although this is a real risk it is regarded as low since such a 
dramatic schedule change would normally occur enough in advance to permit the major 
upgrade that might be required. 


7.3 OPERATIONAL FACTORS 

Operational convenience and flexibility also contribute to the TDCF implementation trade- 
off. These factors are not easily quantifiable, but may be identified as having positive or 
negative, weak or strong effects relative to the trade-off study. 
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7.3.1 Convenience 

Each of the proposed TDCF implementations is in some way more convenient or efficient 
from a. total Project perspective. In Section 6.1.4, the centralization of all TRMM data 
processing, from Level Zero through Level 4, and most TRMM data users at GSFC was 
identified as an advantage of the Pacor TDCF implementation that would permit more 
effective mission development and operation. In Section 6.2.4, the centralization or the 
virtual channel separation and packet demultiplexing and sorting functions at ^e WoC was 
identified as an advantage of the CDOS TDCF implementation that would simplify POLC 
operations and reduce overall Project operating costs. From a Project perspective, while 
both of these features are desirable - centralization at GSFC and centralization of front-end 
virtual channel processing - the centralization of all TRMM data processing capabilities at 
GSFC is considered slightly more desirable- Although these benefits do not specifically 
impact the Level Zero processing function, the centralization of all processing at GSFC is 
also operationally more desirable from a Code 500 perspective. 

7.3.2 Flexibility 

Operational flexibility to accommodate TRMM-unique processing and data handling 
requirements is an extremely desirable feature for the TDCF. The ability and willingness to 
respond to and satisfy new or modified requirements as well as emergency situations may 
be a significant factor in the final trade-off eva luation. 

The TRMM is a relatively large customer to the Pacor, and a relatively small customer to 
CDOS. One potential benefit of being viewed as a large customer is an increase in the 
degree to which the system may be able to accommodate customer-specific requirements. 
Conversely, a potential disadvantage of being viewed as a small customer is the lack of 
influence over the services offered and functions performed by the system. While the 
relative size of the mission does not appear to be a significant discriminator, there may be 
some impact with regard to the flexibility of the TDCF to accommodate TRMM-unique 
requirements. Z 

Since the Pacor will have to acquire an entirely separate equipment string to accommodate 
the TRMM, it is likely that the TRMM-dedicated string will be sized and configured to 
completely satisfy the identified TDCF requirements. In addition, since the Pacor-based 
TDCF supports the TRMM with a separate equipment string and may be viewed in a larger 
sense as a dedicated TRMM Level Zero processing facility, changes in the TDCF 
requirements subsequent to the initiation of operations could be more readily implemented. 
Emergency situations requiring real-time processing or other special processing to support 
data analysis on very short notice can be managed quickly and efficiently without 
interruption from a larger or higher-priority customer. 

The TRMM will probably have little effect on CDOS with regard to TDCF functions and 
services required by the TRMM but not envisioned to be supported by CDOS. For 
example, the functions of the CDOS data archive are only vaguely defined at this time. The 
CDOS archive is required to store data for a period of 20 years; the type of data to be stored 
(raw or Level Zero) is not defined. For the purposes of this study it has been assumed that 
the CDOS archive will store the raw data for a period of 2 years as required by the TRMM. 
If subsequent CDOS archive requirements dictate that only Level Zero data products shall 
be archived, the TRMM raw data would probably have to be transmitted to the GBRS at 
GSFC for storage, since it is unlikely that this TRMM requirement would drive the CDOS 
data archive requirements. 
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CDOS will offer great flexibility in that there will be a broad range of services available to 
users. However, users must select from among the available services and may not be able 
to customize the services to exactly meet all of their data processing and data handling 

needs. 

CDOS will support manned platforms such as Space Station as well as unmanned free 
flyers such as TRMM. In the event of schedule conflicts or emergencies occurring on a 
manned (or large) platform and the TRMM spacecraft, the manned (or large) platform 
would most probably take priority over the TRMM spacecraft emergency and potentially 
result in the loss of TRMM data. 


7.4 TRADE-OFF SUMMARY 

Sections 7.1, 7.2, and 7.3 identified the trade-offs pertinent to the final selection of the 
TDCF architecture. The results of the trade-off analyses are summarized m Table 7-2 for 
the Pacor and CDOS implementations. The trade-offs are quantified to the extent possible. 
Other trade-offs are assigned a relative ranking of low, medium, or high within the 
appropriate context. 

Quantitatively, the CDOS option is significantly lower in cost than the Pacor option. 
Qualitatively, however, the Pacor option appears to have a slight advantage over the CDOS 
option: This advantage could increase or decrease upon finalization of the CDOS 
implementation schedule and identification of the RMA specifications for the Pacor. 


7.5 OTHER ISSUES 

In addition to the trade-offs identified in Section 7.1, 7.2, and 7.3, there are several issues 
that may significantly affect the TDCF implementation decision. The first relates to the 
TDCF performance requirements. The second relates to the assumptions used to develop 
the TDCF requirements and the Pacor and CDOS TDCF architectures. The third relates to 
whether there will be a Code 500 policy for the 1997 time frame that prescribes the Level 
Zero processing facility to be used by TRMM. 

The majority of the TDCF performance requirements specified in Section 3.3 have 
associated with them a "(TBR)", indicating that the values stated in the requirements have 
not yet been finalized. These values must be validated and all "(TBR)"s removed prior to a 
final evaluation of the TDCF implementation. Significant changes in any of these values 
could result in significant cost or performance impacts which could in turn determine the 
final TDCF selection. 


The assumptions used to develop the TDCF requirements as well as both TDCF 
architectures must also be validated to ensure the conformance of the proposed architectures 
with appropriate functional, performance, and operational requirements. Of particular 
interest are the development schedules associated with the Pacor and GBRS upgrades 
(Section 6.1.3) upgrades and the CDOS implementation (Section 6.2.5), and the resolution 
of the type(s) of data stored by the CDOS Archival Data Management Service (Section 
6 . 2 . 2 ). 


Finally, as noted in Section 6. 1.3.1, the recent CDOS decision to support the Packet 
Telemetry CCSDS Recommendation (CCSDS 102.0-B-2, January 1987) strongly sug| ests 
that at some time in the future CDOS will assume mission loads that might otherwise have 
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Table 7-2. Trad e-O ff Study Summary 


Trade-Off Issue 

Pacor 

Implementation 

CDOS 

Implementation 

Cost Factors 



Marginal Development 

$4.5 - 5.9 Million 

Unknown 

Marginal Operations 

$800 ,000/Year 

Unknown 

Communications 

$2X/Y ear 

$X / Year 

Risk Factors 



Development/Schedule 

Low 

High 

Operations 

Low 

Low 

Operational Factors 



Operational Convenience 

High 

Medium/High 

Flexibility 

Medium 

Low 

Other Processing Impacts 

None 

Lower POCC 
Processing Costs 


been assigned to the Pacor. An issue to be investigated is whether Code 500 will establish 
a policy requiring all missions launched subsequent to a to-be-specified cut-over date or 
having data rates greater than a to-be-specified maximum rate to use the CDOS Level Zero 
processing capability. If there is a high probability that such a policy will in fact be 
implemented prior to the TRMM launch, the trade-offs presented in this section may 
become irrelevant. 
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8.0 RECOMMENDATIONS FOR THE FINAL TDCF SELECTION 
PROCESS 

This document has identified the baselin e TDC F requirements and the assumptions upon 
which those requirements are based, defined two possible TDCF architectures that satisfy 
the specified requirements, and presented the various trade-offs associated with those 
architectures. The final selection process regarding the TDCF architecture must include the 
resolution of several fundamental issues, including the validation of the requirements and 
their underlying assumptions, the validation of the trade-off analyses subsequent to any 
changes in the requirements or assumptions, and the likelihood of a future Code 500 policy 
regarding the use of institutional LZP facilities. The proposed TDCF architectures 
presented in this report should be re-evaluated if requirements or assumptions change and 
as new information becomes available. 


8.1 VALIDATION OF TDCF REQUIREMENTS AND UNDERLYING 
ASSUMPTIONS 

A TRMM Science Team has not yet been formally established by the Project. It is 
necessary to identify the TRMM Science Team as soon as possible to confirm the propriety 
of the TDCF requirements and assumptions upon which the architecture options and trade- 
offs are based. 


The TDCF requirements presented in Section 3 were developed on the basis of historical 
Level Zero processing functions and the mission assumptions identified in Section 4. As 
the TRMM project progresses, both the assumptions and the requirements should be 
carefully reviewed by the TRMM Science Team and coordinated with the Project and with 
Code 500 to ensure both the scientific appropriateness and the functional feasibility of the 
TDCF requirements. It is critical that the TDCF be neither over-specified nor under- 
specified and that all of requirements levied on the TDCF be clear and appropriate. Over- 
specification, under-specification, or inaccuracies in the requirements due to inaccurate or 
incorrect assumptions could result in the selection of a TDCF architecture that does not 
cost-effectively provide the necessary functional, performance, or operational capabilities. 


Requirements that are currently considered issues are primarily performance requirements 
whose stated values must be validated as the TRMM Project is refined. Performance 
requirements potentially of issue include the number of virtual channels to be supported 
(3.3. 1.2); the data transmission rates from the TDCF to users (3.3. 1.6 through 3.3.1.10); 
the daily real-time (3. 3. 2. 2) and quick-look (3. 3. 2.4) processing capacities, the 2-year 
storage of raw data (3. 3.3.2); temporary storage requirements for production data products 
(3. 3. 3. 4); and operational requirements for MTBF (3. 4.1.1), MTTR (3. 4.2.1) and 
availability (3.4.3. 1). These requirements generally have a "(TBR)" associated with the 
performance specification value. 


8.2 RE-EVALUATION OF PROPOSED TDCF ARCHITECTURES 


Once the TDCF requirements and assumptions have been validated by the TRMM Project, 
the proposed TDCF architectures should be reviewed to ensure their continued 
conformance with the TDCF requirements. This evaluation should also take into account 
new information not available at the time this study was conducted. For example, the 
CDOS Level UI requirements specification scheduled for release in late 1990 as part of the 
Request for Proposal (RFP) for the CDOS Phase C/D implementation should be carefully 
reviewed in conjunction with the CDO S assumptions and scenarios developed in this 
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report. The proposed architectures should be iterated as necessary to incorporate any 
changes in the TDCF requirements or assumptions as well as additional supporting data. 


8.3 VALIDATION OF TRADE-OFF ANALYSES 

Subsequent to the validation of the requirements and assumptions and any necessary 
modifications to the proposed Pacor-based or CDOS-based TDCF architectures, the trade- 
offs presented in Section 7 should be reviewed and updated as necessary. For example, 
changes in the currently specified data transmission rates to users could impact the 
communications costs associated with each proposed architecture. 

The development and operations costs associated with each TDCF implementation should 
be revised to reflect any modifications to the architectures. These estimates should be 
refined upon completion of current analyses being conducted by Pacor and CDOS staff. 

The TRMM-specific processing costs incurred in the production of TRMM Level Zero data 
products should be assessed and incorporated in the cost trade-offs presented in 
Section 7.1. Neither Pacor nor CDOS currently has in place a methodology for 
apportioning the cost of processing resources required to support individual users. Studies 
are underway for both systems to establish a means of tracking resource usage by user, the 
assignment of resource costs would be a natural extension to these studies. 

The actual development risks associated with the CDOS implementation should be assessed 
as better data becomes available. The Statement of Work (SOW) included in the RFP for 
the CDOS Phase C/D implementation should provide the required insight. The RFP is 
currently scheduled for release in late 1990; a preliminary version may be available at an 
earlier date. 

Similarly, the operations risks associated with the Pacor implementation should be 
evaluated and revised if it is merited. 


8.4 OTHER CONSIDERATIONS 

Section 7.5 identified a critical issue in the TDCF architecture evaluation to be the 
possibility of a future Code 500 policy regarding the use of CDOS for any new missions 
requiring a Level Zero processing capability. The probability that such a policy might be 
implemented should be carefully investigated and quantified, since such a policy would 
potentially preclude the selection process and negate the need to update the trade-off study. 
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APPENDIX A - GLOSSARY OF TERMS 


Ancillary Data - Data other than instrument data required to perform an instrument s data 
processing. They include spacecraft/platform engineering data (e.g., orbit data, attitude 
data time information, pointing information, optics temperature, structure temperature, 
instrument mounting alignment), calibration source data and data from other 
instruments (e.g., cloud information d eri ved from a second instrument, status or items 
in a second instrument which could create interference with the instrument data being 
processed, map data, atmosphere temperature grids). 

Auxiliary Data - Data not available from on-board sources, but obtained from other 
sources which are used with ancillary data in the processing or interpretation of given 
data set. Auxiliary data include FDF processed refined/repaired ancillary data and can 
include engineering data from external sources, system test data or management data. 

Captured Data - The set of all return link data that have been stored on a nonvolatile 
storage medium by the TDCF prior to processing of any kind. The captured data 
include all spacecraft/platform data, instrument data, and ancillary data downlinked 
from the spacecraft. 

Commands - The set of data that effect and control instrument and spacecraft operations^ 
Commands are generated by the POCC as necessary to ensure spacecraft health and 
safety, and by the TSDIS SOCC to ensure proper instrument operation to maximize the 
utility of the instrument data. 

Data Product - One (or more) processed Primary Data Set(s) and associated quality and 
accounting information. 

Engineering Data - The set of data comprising spacecraft engineering data, health and 
safety engineering data, and instrument engineering data. 

Health and Safety (Engineering) Data - That set of Spacecraft Health and Safety 
Data, Instrument Health and Safety Data, and possibly Instrument Science Data 
required to operate and maintain all on-board spacecraft systems, including all scientific 
instruments, within a predefined safe operating regime, including appropriate 
emergency safe states. 

Housekeeping Data - See Spacecraft Engineering Data 

Instrument Data - All data originating from within the scientific instrument systems. 

Instrument Engineering Data - Data produced by engineering sensor(s) of an 
instrument, used either for operating the instrument or for processing the science data 
generated by the instrument. 

Instrument Health and Safety Data - That subset of instrument engineering and/or 
science data needed to permit the instru ment to be operated within a predefined sare 
regime including appropriate emergency safe states. 

Instrument Science Data - Data produced by the science sensor(s) of an instrument, 
providing direct or indirect measurements of the external physical parameters being 
investigated by the instrument. 
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Level Zero Processing - That processing performed by the TDCF to yield real-time, 
quick-look, or production data products. 

Orphan Packets - Packets that have become separated from and were not included in the 
appropriate Primary Data Set during production processing. Orphan packets may result 
from an incomplete or interrupted tape recorder dump during the scheduled TDRS 
acquisition session. Orphan packets are anticipated to be encountered very 
infrequently. 

Playback Data - Spacecraft/Platform Data, Instrument Data, and Ancillary Data that have 
been recorded on one of the TRMM spacecraft's solid state recorders during the 
previous orbit for replay to the ground during the next scheduled TDRS contact. 

Primary Data Set - The set of all packets having a single APID, and having a source 
packet time code between a predefined start and stop time. For real time and quick-look 
processing the start and stop times coincide with the scheduled start and stop times of a 
TDRS acquisition session; for production processing the start and stop times coincide 
with a 24-hour period commencing at midnight. 

Production Processing - The TDCF process that separates virtual channels, 
demultiplexes packets, and, on the basis of the APID, merges real time and playback 
packet channels, time orders the primary data set, deletes redundant packets, performs 
data accounting and analyzes data quality. The resulting production data products are 
transmitted to users within 24 hours of receipt of the last bit of data comprising the 
primary data set by the TDCF. 

Quick-Look Processing - The TDCF process that separates virtual channels, 
demultiplexes packets, and, on the basis of the APID and the established quick-look 
schedule (TDRS acquisition session), time orders the primary data set, performs data 
accounting, and analyzes data quality. The resulting quick-look data products are 
transmitted to users within 2 hours of receipt of the last bit of data comprising the 
primary data set by the TDCF. Quick-look primary data sets are limited to a single 
TDRS acquisition session and playback packet channel. No merging of real time and 
playback data is performed. 

Raw Data - Data as it is received from the spacecraft, prior to any processing on the 
ground. Raw data becomes captured data upon storage of the raw data on a nonvolatile 
medium by the TDCF. 

Real-Time Processing - The TDCF process that separates virtual channels, 
demultiplexes packets from the real time virtual channel (if required by the user), and 
summarizes data quality and accounting information for packets having specified 
APID(s) received during a single TDRS acquisition session. The real time data are 
forwarded to users within 1 second of receipt by the TDCF. 

Real-Time Telemetry (Real-Time Data) - Spacecraft/Platform Data, Instrument 
Data, and Ancillary Data that are downlinked to the ground immediately after being 
generated on-board the spacecraft during a scheduled TDRS acquisition session. Real- 
Time Telemetry Data are also recorded on one of the TRMM spacecraft's solid state 
recorders to ensure against the loss of data generated during a TDRS contact. 

Science Data - See Instrument Science Data. 
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Software Updates - Revisions to on-board software to correct errors or wenh^ce on- 
board operations. Software updates are generated on the ground by the TSDIS SOU_ 
or the POCC and uplinked to the spacecraft via the SN. 

Spacecraft/Platform Data - All downlinked data originating from spacecraft level 
systems excluding that data generated by the scientific instruments. 

Spacecraft Engineering/Housekeeping Data - Data which describes the physical 
condition and operation of the spacecraft platform and interfaces to the instruments on 
the platform. Parameters might include temperatures at specific points, voltages, power 
levels, switch settings, recorder status, on-board computer status, etc. 


Spacecraft Health and Safety Data - That subset of the Engineering Data required to 
maintain all on-board spacecraft platform systems within a predefined safe operating 
regime. 


TDRS Acquisition Session - The period of time during which data are received from 
the TDRS. 
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